When should a cb_manager be allowed to see a timeframe / restriction?

[hansmorb]

This discussion was extracted from #1784 , where it was mostly concerning timeframes. In addition, this contains summarized discussions from internal chats and is copy pasted and sloppily translated, sorry for that. We are trying to bring this question forward to the community. This behaviour is controlled through the getAdmins function in the Model/Timeframe or Model/Restriction class.

Core discussion

AFAIK, the current behaviour is behaviour 4. We though about switching to behaviour 1 at one point but I am pretty sure the switch was never made.
A conceptional issue arose from this that we need to discuss. The question is, when should a CB manager be allowed to edit a timeframe:

1. If they are both the admin of the item AND the location (thus only timeframes they could have created themselves)
2. If they are the admin of the item
3. If they are the admin of the location
4. If they are either of the one (2 or 3). (<- CURRENT behaviour)
5. Have additional admins for timeframes
6. Switch between 1 or 4 in the admin settings

Arguments for / against specific settings

No 1

most predictable behavior but would also mean that an admin cannot be easily defined by just making them the admin of the location, thus allowing them to change all the items at their location. This would mean a lot more work to properly define an admin because they also need to be assigned to all the items they will manage in the future. -> Very strict

Questions are concering the user experience for the following cases:

What is the user experience for the following combinations:

(A) Location admin (yes) Item admin (yes) => User is automatically timeframe admin
(B) Location admin (yes) Item admin (no) => Cannot edit timeframe
(C) Location admin (no) Item admin (yes) => Cannot edit timeframe
(D) Location admin (no), item admin (no) => Cannot edit timeframe

Combinations A and D are clear and straightforward.

But in B and C, there would be users in the role of CB manager who are item/location admins but cannot edit the timeframes.

(B) User is a location administrator and wants to change the timeframe of the items for their location. To do this, they must now also be the item administrator for each item. If they are, they can then also change all items.
(C) User is an item administrator and wants to change the timeframe of their item at a location. To do this, they must now also be the location administrator for the item. If they are, they can then also change all locations.

In alternative (4), the opposite is relevant, because now I might want to prevent the time frame from being edited by location/item admins, but unfortunately I cannot.

I believe the categories of post admins (item admin or location admin) are the wrong terms, and we should approach this more from the perspective of authorisations/permissions.

No 2 & 3

unclear for users why only item / location admin matters

No 4

4. Very flexible BUT behavior is unpredictable. Useful in following scenarios:

(Multiple item location):
One location has multiple items (in our case about 10) and wants to change their opening hours through the timeframe. The cb_manager is only assigned to the location. Previously, they could edit all their timeframes because they manage the location. Now, they have to be assigned to all 10 items at the station to make the changes there respectively. On the other hand, they can now create restrictions and timeframes, which they previously couldn't.

2nd scenario (Sailing club):
We have multiple instances where the cb_manager is used so that members in the club can see their respective bookings. The example would be a sailing club with multiple boats at one location. Members of that club only have to be made manager of the location, not of all the boats. This would mean, that they now have to assign each member to the items as well.

Ruthenicke scenario (German):

"Ein Anwendungsbeispiel ist unser Rad Ruthenicke, das monatlich zw. 3 Brandenburger Standorten wechselt. Die Radzuständigen (Radanbieter) sollen diese wechselnde Buchbarkeit selbstständig managen können, auch ggfs. für künftige zusätzliche Standorte. Umgekehrt sollen Standort-Zuständige für ALLE bei ihnen buchbaren Räder (bisher bei uns nur max. 2-3) die Ferienschließungen u. Sperrungen definieren können. Bei Holiday Timeframes ist da ja passenderweise schon per Mehrfach-Radauswahl auf einmal möglich, aber ja nur für zugewiesene!"

Additional problem:
No 4 has contextual limitations and breaks down for timeframes with multiple items assigned.

Currently, the options “All” and “Category” for timeframe assignment are only available to admins, because we cannot evaluate them in a context-dependent way. In theory, “All” could mean “all items belonging to the CB Manager,” but we deliberately do not implement that. As a result, any timeframe set to All or Category is excluded.

Still, it becomes confusing when a timeframe applies to multiple locations. For example, if a timeframe is assigned to several locations and includes multiple items, what are the requirements? Does the admin need permission for at least one location, at least one item, or for all items involved?

No 5

Would mean additional role, question is what happens when timeframes expire? Do they stay admins? What about multiple timeframes for one location / item.

No 6

Even if configurable, what should be the default setting?

Weirdness in the code

#1787 made the sole responsible part of code the commonsbooking_isUserAllowedToSee function to determine if a specific user may see the post in the backend. This is irrespective of commonsbooking_isUserAllowedToEdit, which only concerns bookings. MEaning even if commonsbooking_isUserAllowedToEdit is not true for a specific user and post, they may still see in the backend. Best to not concern yourself with that but just look at the getAdmins function of Model/Timeframe and Model/Restriction.

Input, a better structured version of the above texts as well as other scenarios in which you are using the permission management are welcomed.