We didn't reset the capability flag and also didn't resend M155. Now we
do at least the latter if we detected that the printer supports
temperature auto reporting earlier.
A centralized plugin blacklist read from plugins.octoprint.org on server
start now allows us to stop plugins from being loaded that are known to
cause severe issues with OctoPrint's regular operation.
Blacklist entries can be restricted for specific plugin versions &
OctoPrint versions, allowing for very granular control of any kind of
blocking.
Additionally users may disable blacklist processing in general (an
opt-in wizard and a new section in the settings have been added) and
at server start via the new --ignore-blacklist parameter available for
"octoprint serve" and "octoprint daemon".
If a plugin is blacklisted, OctoPrint will not even import the
plugin module in question (if only a plugin key is specified OR a key
and a version and the plugin's version is already known during import
time, which is the case for plugins loaded from entry points) or at the
very least stop the plugin from being enabled (if a plugin key and a
version is specified and the plugin's version is only known after
loading, which is the case for plugins loaded from directories).
Sets server.startOnceInSafeMode flag to true. Probably easier for a lot
of people than editing a config file or running OctoPrint manually from
command line, in case the built-in "Restart in safe mode" system command
is not an option.
We so far only protected the binding process itself against errors
triggered inside view models. Now we are also more resilient against
issues arising in view model callbacks like onBeforeBinding,
onBoundTo and onAfterBinding as well as exceptions during plugin
instantiation itself.
Triggered by jneilliii/OctoPrint-TPLinkSmartplug#19 which was also
reported on OctoPrint's tracker as #2168, #2170 and #2171 and on OctoPi
as guysoft/OctoPi#427.
There are too many printers out there with crappy electronics that are
just waiting to go up in smoke, and people keep leaving those alone
because "they are monitoring them via OctoPrint, so nothing can happen".
So let's add a safety warning, in the hopes that will bring at least
some people to their senses or at the very least force them into making
the conscious decision to blow all warnings into the wind.
Firefox doesn't trigger dragleave if the mouse leaves the browser
window to another window on top during an active drag. That leaves
OctoPrint stuck with the drag-n-drop overlay.
Adding a timeout for dragover for only Firefox that clears the overlay
solves this issue.
Solves #2166
We also reflect that in the Cura profile import dialog by checking and
disabling modification of the corresponding checkbox if no profiles are
yet available.
Plot area was wrongly sized due to (invisible) X axis tick labels.
We now initialize an empty plot to min/max timestamps of "now" to
circumvent this. Additionally plot was not properly initialized on
initial load of page due to onAfterTabChange not firing for the first
tab.
Also added a bit for tick labels.
Wasn't properly revalidating when an already registered slicer switched
between unconfigured and configured.
Also adjusted data format version tracking on files and slicing API to
match.
We might add fields to things like file entries (e.g. "display") and in
such cases want to refetch the list even if the files itself didn't
change, to make sure those new fields are available to the clients.
See https://github.com/foosel/OctoPrint/issues/2111#issuecomment-337164940
Increased scrollbar width of file list and plugin repository list to
10px (from 5px). Fixed scroll bar hiding itself on initialization due to
alwaysVisible not properly persisting the initial binding.
Enhance knockout binding syntax for slimScrolledForeach: slimscroll
initialization parameters may now be provided during data binding via
the additional slimscroll property accepted as part of the extended
foreach syntax, e.g.
slimScrolledForEach: {data: ..., slimscroll: {alwaysVisible: true, ...}}
Implements #2111
Files (and folders) are still slugified to ASCII for storage on disk,
but now the original filename is stored alongside in metadata.yaml
and used for display in the file list and print status.
The slicing dialog also inherits that display name for use as base
for the suggested GCODE name.
Internally, everything still depends completely on the slugified
ASCII version.
This implements #2094
This would normally not fly at all but we give it a pass here since we
only use that module for auto detection anyhow (and probably not for
much longer since that approach is simply too error prone).
Adapted from
https://github.com/foosel/OctoPrint/issues/2138#issuecomment-334117910
by @dtynan.
Solves #2138 until I come up with something better
If the filename contained a [] pair, the file would not match the glob
pattern used for selecting for deletion.
Backporting the glob.escape function from Python 3.4 and using it here
should fix that. We only use our own ported version if glob.escape
doesn't exist - that should reduce redundant code once we become Python
3 compatible.
If the temperature graph was not on the first tab, the plot would be
initialized without being visible, causing some sizing issues and
alignment issues with the Y axis ticks.
Forcing the plot to only get initialized once visible solves these
problems.
Fixes#2147
