Add support for events inheriting ACL from its series (via different merge modes)

[LukasKalbertodt]

We procrastinated this for a long time but we should have support for this ACL mechanism. It's described in these docs.

The way I see it, we have to implement the logic for all possible merge modes. Otherwise we cannot correctly perform authorization as Opencast specifies it. The logic is fairly straight forward, but we have to see whether we "implement it at query time" by making SQL queries and the Meili query more complex, or whether we have a cached "merged" ACL somewhere.

And how do we get the current merge mode? We can force admins to configure it in Tobira, duplicating that value. Or we could somehow transfer it from Opencast to Tobira. Is there an API already maybe?

Random thoughts of mine:

• The ACL of the series have a dual role then. Its "write" actions are used to see whether people can add videos to a series or edit the series metadata. But the ACLs also might be used for all events. I doubt this is a problem in practice, but it still seems weird to me.
• In Tobira there is currently not natural way to store "this event has no ACL attached to it". In fact, even the harvest API assumes that this is always the case. We can send an empty ACL but that's different than having non at all, right? And "having none at all" is required for the "override" rule to work at all. Our uploader also needs to support not attaching ACL at all.
• The Harvest module in Opencats retrieves the event ACLs from the search service. Do we already get ACLs merged by Opencast? And are they updated correctly so that we already have everything working?!
• The visibility selection to control ACL in the uploader should be configurable #1006 is related, but independent of this. No merge mode inherently disallows specifying ACLs for an event. So if Bern wants events to always have exactly the same ACL as the series, that needs to be a separate toggle.

[LukasKalbertodt]

It indeed seems like Tobira is already using correctly merged ACLs since the data is retrieved from the search service.

That brings up the question of how the ACL UI for existing events should work. Or well, for the uploader as well. Should it only edit the ACL attached to the event itself? But we somehow have to show users the resulting ACL after merging with the series?

[LukasKalbertodt]

So I thought about this a bunch more. A summary.

Lets say there is a series in Opencast with ACL S, and an event with ACL E that is part of the series. The resulting/effective ACL is S+E. This is what's used for authorization (i.e. to check whether someone has access). The exact value of S+E depends on the merge mode, but the specific mode is not too important for these considerations.

Tobira currently only knows about S and S+E, but not about E and also not about the merge mode configured in Opencast. And while the + notation might imply it, no, we cannot derive E from the other two (S and S+E). Does Tobira need to know about E? Lets list all ways how Tobira uses the ACLs of items:

• Event authorization checks: are performed with S+E, which is correct. No problem here.
• Series authorization checks: are performed with S, which is correct. No problem here.
• (In the future) Showing ACL information on video page: I think showing S+E is fine (or even good) here, as that's exactly the same ACL used for authorization, which is what the user wants. One could talk about showing S and E separately, but I think that would overload the video page anyway. So no problem here.
• ACL UI for the video uploader
• ACL UI for editing existing event ACLs

For the latter two, we run into problems. When "saving" the specified ACL, we store it as E' (i.e. the new event ACL). Only S and E are a "source of information" that is stored somewhere, S+E is only ever derived. So storing it as E' is the only valid option.

• But since we only know S+E, not E, currently S+E is shown in the ACL editor. If the user would save that without changing anything, we would set the new E to S+E, i.e. now the event ACL would contain the merged ACL, including roles that were previously stored in S only. This doesn't immediately break anything as the new effective ACL S+(S+E) are equal to S+E, but it still leads to unintended consequences:
  • Suppose ROLE_FOO was only mentioned in S before, with read and write access. After this interaction, E also contains ROLE_FOO. If you then edit S so that ROLE_FOO only has read (and no write) access, then the effective ACL of the event still gives write access to ROLE_FOO, since E does it.
  • If a user wants to remove access from one user and they remove it in the ACL UI and save, and if that role wasn't defined in E to begin with, but in S, then the changes made by the user achieved nothing, as only E was changed and S (and thus S+E) still contains the unwanted user. That's confusing.
• When setting E (in case of the uploader or the editor), Tobira takes that value and treats it as effective ACL. This is wrong. It is fixed via updates over the harvest API (where the merged ACL arrives), but for some time it is wrong (luckily in the less bad way, where fewer people have access than should have).

To fix these, Tobira would need to know about E and the merge mode. That would require changes to the harvest API and Tobira's DB, among other things. But even with that data, solving the first point is non trivial and interesting from UX perspective. If we just present E in the ACL UI, then that's misleading as potentially more people have access than the user sees there. So we somehow need to show S and/or S+E as well, with the UI greyed out of course. Just showing S with the heading "access derived from series" seems fine at first, until you realize the merge modes aren't that trivial (speaking about roles vs actions) and we surely do not want to explain them to our users. So I think we need to show S+E. We can still link to series ACL edit page then, if a user really wants to see S.

Alternative UI design (not viable IMO)

An alternative would be to show one ACL UI, with some entries (those from S) being greyed out. But that also doesn't quite work or is at least suuper complex, e.g. if S grants read access to one role and E grants write access to the same role. It's completely unclear how to represent that in the UI. So I don't think this is a good idea, even if it sounds nice first.

It is worth noting that the ACL editor in the admin UI has the exact same problem! S+E is shown/loaded into the editor, but when saving, it is saved as E.

But yes, I think this is it. The ACL UI problems are the only ones.

[LukasKalbertodt]

We decided in today's meeting that this is a low priority for us. With #1006 (with this enabled), this is a non-issue. So this is only a problem for institutions using merge modes and letting users edit the event ACL. Also, this has been broken in the admin UI forever and no one really noticed it there. It makes sense to not sink a ton of time into this now.