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.

[dagraf]

I prefer (d), too. Here my thoughts:

• I think, we need its pro's "shows the user the immediate consequences of their actions" and "lets the user decide what to delete, side stepping all the ambiguity we had above." With all other options there is a lot more explanation for all new administrators and all adopters (and in (c) even users) needed.
• In ILIAS, we have something similar which works fine for us - with no user complaints or questions (as far as I know). In ILIAS, an administrator or teacher can insert the same Opencast series in different places (called 'Courses'). If an admin then deletes this series in one of this places he gets asked wether he wants to delete this series also in the other places/courses. Therefore, (d) would integrate well for all ILIAS adopters.
• I think, we also need to take into account what we want to happen, when a user/administrators deletes an Opencast series in Tobira. Which I think we need better sooner than later. There, I suggest to also should tell users/administrators where this series shows up in Tobira and give him the choice to delete this page.

[LukasKalbertodt]

I will talk to Arne to maybe get an estimate how much time it will cost to implement (d).

Davids last point is interesting and yes, the same should work when deleting in Tobira. And probably also for events. But this made me think of a slight problem: when deleting a series in OC, how do we know that the Opencast user may delete pages in Tobira? If it has ROLE_ADMIN, that's no problem. But what if not? We surely don't want anyone with access to the Admin UI to be able to delete any pages in Tobira? @oas777 do your content managers all have ROLE_ADMIN? But yeah I suppose you can make it configurable somehow. So not a huge problem, but one we should keep in mind.

[oas777]

What's a "content manager"? Someone allowed to create/manipulate Tobira content pages? And is David referring to them? Or any user deleting a series he/she created? Or that was created for him/her by the OC admin? Stay tuned for more questions at 4pm.

[owi92]

Let me add my two cents and a 5th variant of solving this (which is somewhat ignoring your previous discussion and probably much less thought-out than Lukas' suggestions).

Having worked quite a bit now on the implementation of how series are (or will be) managed in both Tobira and the Admin UI (regarding Tobira pages at least), I find it a little odd that "series pages" do not follow the same principles as "video pages", and would in fact suggest that we change that.

What I mean by this is:

• (a) Have a fixed structure for series pages that cannot be changed (like video pages).
• (b) Do not allow any sub-pages for series pages (like video pages).
• (c) Do no create new realms that are mounted in the page tree for new series.*
• (d) Add "share" and "manage" buttons to these new series pages (like the ones we have on video pages). We already have requests to add a "share" button (or at least an rss button) to series, and now that "series details" and "series ACL" management pages (like the ones we have for videos) are getting added, having a "manage" button is a natural conclusion.

Doing these things would mean that "deleting series" via Admin UI would follow the same rules as deleting videos, without extra implications of having to consider what happens when the series is deleted.

*I do realise that especially (c) goes against what Lukas said in the top comment:

The ETH for example likes to mainly automatically "publish series to Tobira" so that they can be reached via the main navigation

We can still offer that feature (which, yes, brings us back to the issue at hand). But:

• It is already possible to unmount ("depublish") series via the Admin UI and this was implemented without worrying about weirding out users with "quantum entanglement", and so far, there have been no complaints (granted, our user base is still rather small or more like non-existent). Right now unmounting is only possible when the page doesn't have any other content, but that can be changed.
• We would essentially treat the pages formally known as the "series page" as a regular realm.
• "Mounting in Tobira" just becomes adding a block of that series to a page (no matter if the page in question has other content or sub-pages).
• Deleting a series would simply remove the series block.
• We can still have special cases where a new page is created or a previously empty page without sub-pages is used, in which case the series' name is used as new realm name. Deleting a series with such a page would also remove the series block, but in addition change the name of the realm to its path name (this is also already done when a series is unmounted from an otherwise empty page with sub-pages. If such a page has no sub-pages, unmounting the series also removes the whole page).

I might be wrong here, but I think this approach would combine most advantages layed out in Lukas' original suggestions while also mitigating the disadvantages, leading to an overall nicer experience on both the Tobira and the Admin UI sides.