System wide API key now offers a generate button like the user
API keys. Setting the API key directly to a value via the settings API
endpoint is now no longer possible, which should prevent setting it
accidentally thanks to the browser prefilling things where it shouldn't.
No delete button is offered for the system wide API key since it will
get automatically regenerated on server start if not set, so
regeneration is the only functionality here that makes sense.
If no API key is set in the user settings, the "delete" button is now
disabled. If a key is already set and a new one is to be generated, a
confirmation dialog makes sure this is really what the user wants. Same
for deleting an existing API key.
Both the system wide API key and the user specific API keys will now
only display a QRCode if there's actually a value for the key.
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.
* show special error if timelapse can't be rendered due to no frames having
been captured
* inform user during print about repeated capture errors
* do not start post roll recording if after a print no frames were captured at all
* also interpret non-ok-ish return codes from snapshot url as capture error
* documentation for CaptureFailed event
They are still useful for other clients than the core application. Renamed them to fit the
general naming on the API however:
* pathForElement is now called pathForEntry
* elementByPath is now called entryForPath
Also added API docs regarding header encoding, incl support for RFC 5987
for filename fields in Content-Disposition headers in multipart/form-data
parts, incl. an example of an upload request with a utf-8 encoded filename.
(Let's be realistic here)
Introduced new "additionalNames" property on viewmodel declaration
to allow for registering alternative lookup names for a view model.
The freshly renamed FileViewModel now resolves as both "filesViewModel"
and "gcodeFilesViewModel", making the renaming backwards compatible
Documented all that stuff (and some more)
Added name and path various event print job events and
the upload event, deprecated the file property.
Had to move event triggering of the print job events to
the printer implementation, since the file manager
is not available in the comm layer. Added new callbacks
to the PrinterInterface to allow for that to be possible.
RepRapFirmware enumerates the gcode files starting at /gcode, it will
also interpret any relative path as being relative to that folder.
However a full absolute path will actually interpret as from the real
root of the SD card :-(
(cherry-picked from ac68570)
Events SlicingProfile(Added|Modified|Deleted). Initially thought to be necessary
to properly refresh available profiles in slicing dialog, not needed for that after
all but still left in and documented, might be useful for someone.
This fixes a simple typo in the API doc for fetching slicing profiles. The previous example had /profiles appended to it, whereas it should just be /api/slicing to fetch a list of all slicers and profiles.
"Hello" command sent to printer to trigger initial handshake can now be
configured. Commands that _always_ necessitate to be sent with checksum/
line number (e.g. M110 on Marlin) can be configured as such too.
Also fixed an issue causing the "Hello" command to not be actually enqueued
first thing on opening a connection. Seems to not have caused harm in the
wild, but was unintentional.
(cherry picked from commit 5c2ae37)
The client now tries to detect if it's fast enough to process the
state updates usually send every 500ms, and if not notifies the
server to throttle the rate (e.g. to 1/1s, 1/1.5s etc).
Additionally, since the terminal tab of the client turned out to
be quite CPU intense when line number calculation, filtering etc
is enabled, the terminal tab now also falls back into a bit less
fancy mode if it detects its being processed too slow and optionally
even disables logging completely during printing (where a lot
of log messages need to be processed in a minimum amount of
time).
That way the UI should stay responsive even on very low powered
clients (e.g. chromium on a Pi), while printing.
Having the plugin commands on the first level of --help proved to be
a bad idea since it basically kills every chance of lazy loading the (expensive)
plugin context. Using a sub command for anything plugin related allows us
to only fire up the plugin context if a plugin command is expected, saving us
some precious seconds of operation in all other cases.
For conformity reasons the dev sub commands were now restructured
similarly.
