Reorder from name/type/priority/updated to name/updated/priority/type.
The new ordering moves the more important info into (according to Blender
Studio) view when the job table is narrow.
Try to get the `.editorconfig` and `.prettierrc` files as close as possible
to the formatting that was used in Flamenco. Because these files weren't
here during most of Flamenco's development so far, having them caused quite
a few changes in the webapp files.
No functional changes intended.
When the worker is started with `-restart-exit-code 47` or has
`restart_exit_code=47` in `flamenco-worker.yaml`, it's marked as
'restartable'. This will enable two worker actions 'Restart
(immediately)' and 'Restart (after task is finished)' in the Manager web
interface. When a worker is asked to restart, it will exit with exit
code `47`. Of course any positive exit code can be used here.
Rename the add-on from `flamenco3-addon.zip` to `flamenco-addon.zip`.
It still contains the same files as before, and in Blender the name of
the add-on has not changed.
As it was decided that the name "tags" would be better for the clarity
of the feature, all files and code named "cluster" or "worker cluster"
have been removed and replaced with "tag" and "worker tag". This is only
a name change, no other features were touched.
This addresses part of #104204.
Reviewed-on: https://projects.blender.org/studio/flamenco/pulls/104223
As a note to anyone who already ran a pre-release version of Flamenco
and configured some worker clusters, with the help of an SQLite client
you can migrate the clusters to tags. First build Flamenco Manager and
start it, to create the new database schema. Then run these SQL queries
via an sqlite commandline client:
```sql
insert into worker_tags
(id, created_at, updated_at, uuid, name, description)
select id, created_at, updated_at, uuid, name, description
from worker_clusters;
insert into worker_tag_membership (worker_tag_id, worker_id)
select worker_cluster_id, worker_id from worker_cluster_membership;
```
The support is still fairly minimal. Clusters cannot be managed via the
webapp yet, so the API has to be used directly for that. Workers can be
assigned to clusters via the webapp though.
Brave (and maybe other browseres) refuse to set the 'User-Agent' header
in XMLHTTPRequests, and are vocal about this in the debug log. Since the
OpenAPI code generator always outputs a custom 'User-Agent' header, I've
added some JS code to strip that off when constructing an API client.
Setting the height of a Tabulator can trigger all kinds of things,
including some buggy behaviour where all the jobs would disappear from
screen. Just don't do it unless it's necessary.
- Add a little confirmation overlay before deleting a job. This overlay
also shows information about whether the Shaman checkout directory
will be deleted or not.
- Send job updates to the web frontend when jobs are marked for
deletion, and when they are actually deleted.
- Respond to those updates, and handle some corner cases where job info
is missing (because it just got deleted).
This closes T99401.
Show jobs that have been marked for deletion with a red strike-through
line in the jobs table, and show the deletion-request timestamp in the
job details.
Remove the assumption that a SocketIO job update without "previous state"
set is always an indication that it's about a new job. Soon job priority
will be changeable, and then this assumption will no longer hold.
Add "remove worker" button to the worker details panel. It will
show a little warning when the worker is still running, and also has an
explanation of what removing a worker actually means.
If there are no jobs in the database yet, show a "get the addon" call to
action. This includes the current API URL, which can be copied by clicking
on it.
There is no feedback yet that the copy took place, though.
The blocklist is now shown in the job details, in its own tab. The list
is only fetched when the tab is visible, and doesn't get dynamically
updated yet.
Remove a whole lot of `console.log()` calls. They were useful during
development, but not really suitable for production environments. Because
they also include (potentially large) objects, they can even slow down
the webapp itself.
* Use full-width form
Fitting an input inside a <dl> makes it jump around
* Add button to toggle schedule on/off
* Add button to cancel editing the schedule
* Use time type inputs for Start/End Time fields
* Add help text to "Days of Week" to explain it's only the first 2 letters
No functional change, just name the components with their type first,
so that all 'link' related components are more discoverable and next
to each other.
