Add Create, Edit, Delete for LifeCycle Policies #1004
Conversation
|
This pull request has conflicts ☹ |
|
Use Run test server using develop.opencast.org as backend: Specify a different backend like stable.opencast.org: It may take a few seconds for the interface to spin up. |
Adds a new tab to recordings called "LifeCycle Policies". Much like other tabs this tab displays information on its subject in a table format. Unlike i.e. the events tab, the LifeCycle Policies cannot be changed in any way, just be viewed. Editing is supposed to be added at a later date. Depends on PR opencast/opencast#6139 being merged to make any sense. Similarly, if you would like to test this, your admin interface should point to an Opencast with the PR installed.
Type LifeCyclePolicy was missing on a union type.
Arnei
force-pushed
the
lifecycle-write
branch
from
e7b3c5f to
6d9e5a4
Compare
Instead of only being able to view lifecycle policies, this commit lets you edit them, create new ones and even delete them. Depends on changes to the backend.
Arnei
force-pushed
the
lifecycle-write
branch
from
6d9e5a4 to
c2d1c40
Compare
|
This pull request is deployed at test.admin-interface.opencast.org/1004/2025-12-03_15-05-58/ . |
|
This pull request has conflicts ☹ |
|
This pull request has conflicts ☹ |
|
I have some random UI-related notes that I took when @Arnei recently presented this PR to us internally.
Other than that I had no complaints. Looked very finished and very like the other UIs in this project. |
|
@Arnei I just tried to spin up a test container via |
|
This pull request has conflicts ☹ |
|
This pull request has conflicts ☹ |
Arnei
force-pushed
the
lifecycle-write
branch
from
de284b1 to
9fff939
Compare
|
This pull request has conflicts ☹ |
|
This pull request has conflicts ☹ |
Greater/Less than makes no sense for text values.
Instead of having to type the workflow id and the workflow parameters per hand as strings for lifecycle policies, this adds the proper UI known from other modals.
Adds a new page to the event details. There all active policies that would affect th event are listed.
Bildschirmaufzeichnung.vom.2025-11-17.10-13-36.mp4
Bildschirmaufzeichnung.vom.2025-11-17.10-16-36.mp4
Bildschirmaufzeichnung.vom.2025-11-17.10-30-14.mp4
Bildschirmaufzeichnung.vom.2025-11-17.10-40-51.mp4
|
The structure for targetFilters changed in the backend. There is now another map wrapper that splits filters by metadata catalogs. This commit makes the necessary code changes to accomadate the new structure. Still, the behaviour remains the same, meaning only filters for the common event metadata can be added or changed. This does not add support for other catalogs.
|
Thanks for testing, will take a look at all those bugs. As for your other remarks:
If you reenable a lifecycle policy by setting it to active again, it should run again when the timing condition is met. It won't create tasks for entities it has already created tasks for though. So if you have a situation where you reenabled a lifecycle policy, that policy was triggered according to its timing and that policy should have created a task for a new event but did not, then I would consider that a bug.
I don't see what the benefit(s) of forcing a "public" ACL would be, could you elaborate? |
|
Regarding ACLs... It feels like I'm missing some point... does it make any difference using different ACLs when creating/updating polices? Especially when these actions are restricted to admins only, who can always access all assets? |
|
This pull request has conflicts ☹ |
|
If you restrict these actions to admins only, which is entirely reasonable, then what you do with the ACL does not matter because admins get to ignore the ACL anyway. But then there is also no reason to force them "public". If anything I would enforce "private", to make it entirely clear that no one but the admins is supposed to have access. ACLs for lifecycle policies are not useful if only admins handle them. They are there for a future where we have figured out how to reasonably run lifecycle policies for non-admin users, at least in my opinion. |
The displayed value for a selected value in a metadata dropdown would sometimes be cut off if the string for the value looked something like "Test.Test: 1". This fixes that.
For some reason, if a <Cron> from react-js-cron is a child of <Focustrap>, the dropdowns from the <Cron> will not respond properly. In particular, no options in the dropdown can be selected. This commit introduces a workaround by deactivating the <Focustrap> for the LifeCyclePolicy Modals, the only places where <Cron> is used.
The validation for lifecycle policy filters was not yet respecting the recent changes to the structure of the filters object (which now allows for extended metadata). Validation should now work again, and require at least one filter to be set. Additionally, the workflowId is now also required again.
A filter for a lifecycle policy can have different types, like "text" or "date". When changing from one type to another type, the value selectors should change accordingly (i.e. displaying a date selector for filter of type "date", then displaying a dropdown for a filter of type "text". This was not working, but should be working now.
|
I hope I managed to address all the other feedback. I did not address
because I could not come up with a good idea on how to improve setting a date here (and this could arguably be considered a more general problem as our date pickers work like this everywhere). |
5 participants
Instead of only being able to view lifecycle policies, this commit lets you edit them, create new ones and even delete them.
Includes #943. Can serve to replace it.
Depends on changes to the backend: opencast/opencast#6139. These changes are currently pointed at develop.
To test this, you'll need an Opencast with backend changes mentioned above.
Demonstration:
Bildschirmaufzeichnung vom 2024-12-04 10-45-28.webm