Open Elblinator opened 7 months ago
This are the current definitions, if the user can see the collections:
What should it be in the future? Is it correct to say, that a user can see a structure level, if he can see the corresponding meeting_user?
What about the structure_level_list_of_speakers
. Currently, this depends on the permission list_of_speakers.can_see
. Maybe it can be seen, if the user can see the linked list_of_speaker?
Seems to be that the definition for the countdown (meaning structure_level_list_of_speakers
) is already correct, that's why it was only a note by @Elblinator - feel free to correct me though ;) For the structure level, I would just add a suffix to the "can see" definition: "... OR the user has a meeting user which has the requested structure level set", or would that impact the performance too much? Because that is basically what @Elblinator wrote above.
To refer to another collection is good for performance, because there is a cache. If it was already checked, that the request user can see user X, then it is just a cache lookup. If there is another (complicated) condition, then it could be bad for performance. I think that every time, a user requests a structe_level, he also requests the meeting_user and user.
@Elblinator only asked for the case, that the user can see himself. But I don't think, that this is enough. If the user does not have the permission to see users or list of speakers and he looks at a motion with a submitter, then he can not see the structure level of this user.
You are right, if we want to keep the old structure level behaviour from when it was a simple string, this would be the logical conclusion. So the new rule would be:
The user can see a structure level if he has `list_of_speakers.can_see` OR he can see any of the meeting users from `meeting_user_ids`.
What about the
structure_level_list_of_speakers
. Currently, this depends on the permissionlist_of_speakers.can_see
. Maybe it can be seen, if the user can see the linked list_of_speaker?
And I also agree with this change ;)
You are right, if we want to keep the old structure level behaviour from when it was a simple string, this would be the logical conclusion. So the new rule would be:
[...]
And I also agree with this change ;)
I agree!
Current behaviour: If a participant is only allowed to put themselves on a LoS (is not allowed to manage or see the LoS) their own structure level is not displayed
Reproduction:
autoupdate from the delegate:
autoupdate from the admin:
Wanted behaviour: As a participant you should be able to see your own structure level Note: You should only be able to see the structure level countdown IF you are allowed to manage or see the LoS