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.
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.
- 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.
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.
My way to get things working (I wouldn't call this a "solution" as I don't
know the root cause) was to emit two consecutive "reshuffled" events when
changing tabs in the job details, and to recalculate the table height when
the job type (so not the job itself, but its type info) is loaded.
Add a "Last Rendered" view to the webapp.
The Manager now stores (in the database) which job was the last
recipient of a rendered image, and serves that to the appropriate
OpenAPI endpoint.
A new SocketIO subscription + accompanying room makes it possible for
the web interface to receive all rendered images (if they survive the
queue, which discards images when it gets too full).
It doesn't update automatically yet (still needs SocketIO notifications),
and there is no check yet for whether there is actually any last-rendered
image at all, but at least there is a component that shows the image.
