At least unless we've selected git based tracking over release tracking.
This should greatly reduce the likelihood of not being able to update
due to some git repository corruption issues, as has happened to some
people in the past.
* fa-circle-blank does not exist, replaced with fa-circle-o (see also
report in #1928)
* fa-trash-o instead of fa-trash (same look and feel)
* fa-check instead of fa-check-circle (same look and feel)
* fixed toggleContent binding to also be able to toggle fa icons
* fix deletion spinner in file list (was still using old icon-
classes which of course weren't there anymore and hence not
toggleable)
* icons-ul => fa-ul
* remove superfluous fa class from some places
Follow-up to #1915.
Old default behaviour of showing logged in users the update
notification stays default, but can now be disabled via the software
update plugin settings.
Additionally added the ignore button to the notification for users as
well (and made ignore entry in local storage user specific to still
show notification to other logged in users), plus a small hint that
in order to apply updates an admin is needed. Additionally now hiding
the notification on log out.
Closes#1739
Might confuse users to see that marked up like an error when it's
perfectly normal for some kinds of installs simply because the
specific build folders never were created in the first place.
We now have a global OctoPrintClient, which is the class from which
all clients are derived, and a global OctoPrint, which is a single
instance already setup and ready to use in case we only need one.
It would be cleaner to have clients create that singular instance
themselves, but we need to maintain backward compatibility for now
with how we established the client to work with the 1.3.0 release.
New clients can be create with
client = new OctoPrintClient({ /* options */ });
Alternatively the options can be left out and set at a later point:
client = new OctoPrintClient();
/* ... */
client.options = { /* options */ };
Individual client components register themselves with OctoPrintClient
via OctoPrintClient.registerComponent(name, component) from the
component JS files. Just like before their instances are then
available in the individual client instances under "<client>.<name>",
e.g. "OctoPrint.files".
Plugin components register themselves with OctoPrintClient via
OctoPrintClient.registerPluginComponent(name, component) from the
component JS files. Just like before their instances are then
available in the individual client instances under "<client>.plugins
.<name>", e.g. "OctoPrint.plugins.softwareupdate".
This should make it possible to create dashboard pages utilizing the
JS client that monitor the status of multiple OctoPrint instances,
without workarounds such as having to swap out the options globally
before each request.
See #1681 for the corresponding discussion.
Having that output stay on stderr and hence in shiny red looks way
too alarming considering that it's only a pip update that is not THAT
critical usually (and we don't want to do it automatically anyhow
considering how often that appears to break stuff).
Most caching is left to the client, by utilizing ETag and Last-Modified headers.
Where it was easily achievable, an additional server side miniature cache of intermediary
results was introduced (e.g. for the files). The regular cached decorator was not used
since it targets caching full responses, and the responses in question already contained
client request specific data. Caching "one step earlier" allows better usage of the cache here.
Also introduced a dependency on the scandir module, to get a bit of a performance boost
on os.walk and os.listdir (which have been replaced with scandir.walk and scandir.listdir
respectively). See https://github.com/benhoyt/scandir#background on why that made
sense.
* Allow configuration of checkout folder and version tracking type
via Plugin Configuration
* Display message to use if checkout folder is not configured or a
non-release version is running and version tracking against releases
is enabled
* Clear version cache when a change in the check configuration is
detected
* Mark check configurations for which an update is not possible with
a little exclamation mark
(cherry picked from commit 8666a28)
* Allow configuration of checkout folder and version tracking type
via Plugin Configuration
* Display message to use if checkout folder is not configured or a
non-release version is running and version tracking against releases
is enabled
* Clear version cache when a change in the check configuration is
detected
* Mark check configurations for which an update is not possible with
a little exclamation mark
No need to have templates here, we do it directly from the helper methods.
That also leaves us more options regarding callbacks, classes etc.
Helper methods now take an options dictionary (but still can fallback to the
old signature) containing messages, titles, callbacks etc instead of using
positional arguments for that. Switched code over to utilize that new
calling approach.
