Conversation
|
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. |
|
This pull request is deployed at test.admin-interface.opencast.org/1579/2026-04-20_18-05-42/ . |
Arnei
left a comment
Arnei
left a comment
There was a problem hiding this comment.
Works and makes sense to me. I do like the drag and drop for playlist entries. Below are nitpicks.
I would like to see the PlaylistDetails Icon be blue instead of green. Green is for series.
Arnei
left a comment
Arnei
left a comment
There was a problem hiding this comment.
Actually, pagination might be broken? If I have more then 10 playlists, I still only get one page with 10 items.
This adds the titular table and everything necessary to show all playlists. On its own not of much use, apart from looking at the playlist names. Creating, editing, deleting etc. will be added in a later commit. Needs https://github.com/owi92/opencast/tree/playlist-admin-ui-api to work.
|
Thanks for the review. Pagination should be fixed now. Edit: Sorry, Edit 2: Also forgot about the green vs. blue icon question. Matthias also mentioned that in another issue I believe. But if green is for series, you could also argue that blue is for events, right? |
Features metadata and ACL display and editing. Todo: Figure out UI/UX for adding and removing entries.
I think this project should really get away from scss or at least reconsider and rewrite some styles. Why are there `first-child` selectors with `float: right`? That means you have to write column layouts all backwards, which is unintuitive and confusing. Anyway. This just removes some styles/rules from the `SaveEditFooter` component that would not only hide but completely remove certain buttons from the dom while they're disabled. That can lead to layout shifts and confused margins whenever they do pop in. So with this change, they are now always visible and simply use disabled styles and behaviour when appropriate.
Like most of these playlist related additions, this is heavily based on the structure and components that are used for events and series. I'm sure there is a lot of potential for deduplication, but I don't want to touch too many non-playlist files. I think that should be done in a dedicated PR.
This let users add and removes entries to and from their playlists using a GUI. The UI reuses the drag n drop approach that is present for editing table view columns. Entries are shown with some additional metadata, so they are easier to tell apart if some names are repeated (hopefully).
Events don't remove themselves automatically from playlists when they are deleted. Previously I would just show their UUID, but that isn't very helpful. This will now show an "unknown entry" note, which is slightly better I suppose.
|
Pagination works now. The playlist titles in the playlists table do not render. I swear this should work without an extra TitleCell, just like for description >.> You could argue that blue is for events, or that it is just for everything else (see users, groups). Series is probably a non-blue color, because there was a need for a series details button in the events table, and they wanted it to be visually more distinct from its neighbouring event details button. Is that good design? I dunno shrug |
Yeah you need to clear the browser cache first. Had the same issue. |
2 participants
Originally #1537
This adds the necessary interface elements that are needed to use playlists in the admin interface.
Structure and UI design follows what is already present for events and series, and reuses components whenever possible.
Needs opencast/opencast#7496 to work properly.
Closes #1399
Closes opencast/opencast#6909