Improve "Admin UI Workflow" for deleting series

[LukasKalbertodt]

("workflow" in this comment never refers to "Opencast workflows", but to the generic meaning of the word, i.e. how someone works)

CC @oas777 @dagraf as we just talked about this.

---

Out there, there are some different views/approaches on how Tobira is used. The ETH for example likes to mainly automatically "publish series to Tobira" so that they can be reached via the main navigation, similar to their current video portal. But "series publication" is not a concept/term that Tobira understands. Tobira has a different data model of content pages with blocks. Currently, we have this Admin UI functionality that connects those two worlds/ways of looking at things. It does this by, when creating a series in the admin UI, creating a content page in Tobira with a single series block and configuring the content page to derive its name from the series.

But this mapping is imperfect, mostly notable when the series is deleted in the admin UI. In that case, Tobira will learn of the series' deletion and when attempting to display said content page, in place of the series block, it will show an error box saying "The series referenced here was deleted". Which is correct from Tobira perspective, but unhelpful in the workflow of the Opencast admin. This situation needs to be improved as this workflow is important for at least some.

However, I don't think there is one obviously correct solution, but many each with their own quirks.

Summary: I prefer solution (d). I still wanted to post the full text below as it helped me come to that decision, but if you are short on time, I don't expect anyone to read it.

---

(a) Add marker to pages "delete when series X is deleted"

When creating a content page for a series through the admin UI, this special marker is attached to that page. When Tobira learns that a series is deleted, it will automatically delete all content pages with that special marker with the fitting series. (Alternatively, each series in Tobira could store a special marker "when deleted, also delete page XY", but I think that's just implementation detail and not relevant for users.)

• Open question: is this special marker shown to the user in Tobira (e.g. in the page's settings)? Can this marker then be modified?
• Con: What if someone adds more blocks to the page or adds sub pages? Should it still be deleted (including all blocks and subpages)?
• Con: Doesn't seem like a very general and clean solution, from an implementation perspective. An arbitrary "if this then that" rule.
• Con: From a Tobira user perspective, it might look like spukhafte Fernwirkung -- things automatically disappearing.
• Pro: most obvious and probably straight forward solution.

(b) Auto delete all content pages that look like created by the Admin UI

The content pages created by the admin UI always look the same: they have one series block, their name is derived from that series and they have no sub-pages. If Tobira learns of a series' deletion, it could just delete all pages that look like that.

• Con: There can obviously be false positives, i.e. content pages that happen to look like this (maybe because they are currently being built by a user), but are not created by the admin UI and shouldn't be deleted.
• Con: Spukhafte Fernwirkung like in (a).
• Does not delete pages where a user wanted to add a single small text block. Whether that's good or bad depends on your use case, I suppose.
• Pro: No need to store any additional information like in (a) and a bit less "dirty".
• Adding additional blocks or subpages prevents the page from being deleted. Whether thats a pro (no accidental deletion of data) or a con (could be annoying for Opencast admins) depends on your use case, I suppose.

(c) Treat admin UI created pages as "different kind of page" that have to be converted before being usable as normal content page.

We could somehow mark these pages as special and disallow editing the name and the content blocks, and disallow adding subpages for these. But offer a button "Convert to normal page" in the settings. When series are deleted, all these "special pages" referring to that series are also deleted. But once converted to a normal page (which is a one way process!), it is editable as one would expect, but will not be deleted automatically anymore.
This solution can also be thought of not as "creating a special page", but "mounting a series into the navigation tree directly".

Historical note

This is actually how we first tried to implement this whole thing anyway. We didn't plan on having this "derive name" functionality for example, but just have two kinds of pages: content pages and pages only referring to a series. The problem with this is that if a user wants to add a single block to the page, they couldn't retain the feature of deriving the name from the series, which is annoying. So we added this "name deriving" feature separately. Sadly, I didn't find any detailed reasoning for this decision. But if that's indeed the only reason, it might be fine going with this solution now, but keeping the "name derive" feature of course.

Some relevant links:

• Figure out "series realms" (pages that are derived from a series) #351
• 22f83e2

• Pro: Avoids most of the disadvantages of (a) and (b)
• Con: One way streets are not great in UX design. (Conversion back in theory possible, but annoying)
• Con: Would add a special case to Tobira that needs to be accounted for, adding complexity.
• As with (b): Adding additional blocks or subpages prevents the page from being deleted. Whether thats a pro (no accidental deletion of data) or a con (could be annoying for Opencast admins) depends on your use case, I suppose.

(d) Change admin UI "delete" button and make it also delete page in Tobira

Instead of adding this logic to Tobira, we could also add it to the admin UI like we did with the "creation" part of this workflow. The admin UI "delete series" button and confirmation dialog could be changed, so that it shows a list of pages that the series is linked in (like in the series properties right now). But each entry has a checkbox, which decides if said page is deleted. Each entry could also show the number of blocks and subpages.

The default values of these check boxes is interesting: one could default-check all that look like created by the admin UI (similar to (b)); or Opencast could store which page was created to begin with and only tick that one by default. (To be clear, in almost all cases, only one page will be shown in this dialog and that will be checked by default.)

• Pro: shows the user the immediate consequences of their actions.
• Pro: lets the user decide what to delete, side stepping all the ambiguity we had above.
• Logic in Admin UI instead of Tobira
  • Pro: less complexity and special cases in Tobira. Also: makes sense that the "deletion" part of this workflow is also defined in Opencast, like the "creation" part.
  • Con: Opencast needs to know more about Tobira, there needs to be another "stable" API in Tobira.
• Unclear: how easy is it to modify this part of the admin UI?

---

Now that I've written this all down, I think it's pretty clear that I prefer (d).

[LukasKalbertodt]

Of course, if you have other ideas or pros/cons for these ideas, let me know. Maybe I'm missing something.

[oas777]

Thanks, Lukas, for laying out the options. Some initial comments to get this started, mainly looking at my preferred option (a) while also referring to others:

On a higher level, this issue goes back to responsibility, accountability, and authority (not ownership though). And about dogs and their tails. Series "from the admin UI" have been created by an OC administrator, who is therefore responsible for their fate. That person should be able to follow through with deleting (better word is "unpublish") that series as part of that person's authority over the video portal. If you allow users to mess with that publication by adding blocks or creating sub-pages, that's your decision to make life miserable for the OC admin. Those users can still create that little eco-system of theirs on their own pages and the fact that they might end up with deleted series/videos is part of a policy a video portal should have. Unless you have the time to look at each series/video individually (which I think is where (d) is going).

More to the point, commenting your comments on option (a):

• "Con: What if someone adds more blocks to the page or adds sub pages? Should it still be deleted (including all blocks and subpages)?" I think you should either not allow this to happen at all or restrict this to a responsible editor who knows the policies by which you might unpublish videos. Unless you want chaos and a higher workload.
• "Con: Doesn't seem like a very general and clean solution, from an implementation perspective. An arbitrary "if this then that" rule." What's not arbitrary about "if this comes from the OC admin UI then this content page will be deleted when the series is deleted"?
• "Con: From a Tobira user perspective, it might look like spukhafte Fernwirkung -- things automatically disappearing." Nice one. But that's not how things happen. Either the person/institution responsible for the series asks for its deletion, so there's nothing spukhaft about its disappearance. Or it's part of the life cycle policy people should be aware of. Nothing spukhaft there either, RTFM.
• "Pro: most obvious and probably straight forward solution." That's what I'm saying.

[LukasKalbertodt]

Thanks for your comment. I understand your points. For completeness, could you comment on what you dislike about my preferred solution (d)? What disadvantages do you see there?

Your comment only mentions that it might be time intensive going through all entries. Which is a fair point, but I think it's not a big deal in practice. >99% of series you are talking about will be included in exactly one page which will be marked as "delete" by default in said popup dialog. So most of the time, it's just a quick glance by the admin seeing "ah yes also delete that page". The admin only actually needs to pay attention if there is something unusual (which I expect to be very rare), which the UI can make very obvious. And to be clear: I wouldn't mention user pages in the described dialog. User pages work as you say: "the fact that they might end up with deleted series/videos is part of a policy a video portal should have".

[oas777]

I think my answer is in your question: For <1% of the use cases, I currently wouldn't invest any additional work. Or the other way round: How important is a feature that covers less than 1% of uses cases?

[LukasKalbertodt]

I'm not sure that (a) is really less work than (d). Sorry if I implied this. Also, rereading your general statement:

On a higher level, this issue goes back to responsibility, accountability, and authority (not ownership though). And about dogs and their tails. Series "from the admin UI" have been created by an OC administrator, who is therefore responsible for their fate. That person should be able to follow through with deleting (better word is "unpublish") that series as part of that person's authority over the video portal.

That does rather sound like solution (d) to me actually. You want Opencast to be the central hub, controlling the rest, right? With the page creation in Tobira we already do that: the Admin UI instructs Tobira exactly what to do. And I feel like for deletion/unpublishing the same should happen: Opencast telling Tobira exactly what to do. Instead of Tobira just randomly deleting stuff without explicit control from Opencast/the Opencast admin. And it would make the data flow more consistent with the "page creation" process.

Sorry that I'm arguing strongly in favor of (d) right now, even though I invited feedback :D I asked my colleagues now whether my current preference has any merit to it.

[oas777]

[oas777]

I'm not sure that (a) is really less work than (d).

PS: If it is, we'll have to talk again.