You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Current behaviour:
It is possible for committee admins to get information about meetings they are no part of, if their accounts are part of different meetings
Screenshot:
Reproduction:
Create two committees
create one meeting to both of these meetings
Add a User (Ann) to both meetings
Appoint a different user as the committee admin for the first committee
Login as the committee admin and navigate to Ann
In the table-headers you see "Meeting (2)" even though you are only allowed to see one meeting (the one where you are the committee admin
The following information is the info I got from my local instance
I started it and unsed the automatically called initial data
I additionally created two committees, 26 meetings, 4 users (1 OrgaAdmin and 1 committeeadmin)
The information from the subscription (committee_manager_account_list:subscription):
This is not a relation-list-field, but a []number-field. That means, that for the autoupdate service, it is just a list of numbers, that have no other meaning then being a number. The autoupdate-service does not know, that this numbers are actually meeting-ids and that maybe the user is not allowed to see some of the meetings.
If we want to fix this, we either have to change the concept of the autoupdate-service and make it less generic (I don't recommend that), or we have to remove this field.
This field is not really necessary. It is an redundant field, that contains the result of the calculation, in which meeting the user is.
The alternative to that field is, that every service (autoupdate and client) do not use this precalculation but do the calculation them self. Since the introduction of meeting_user, this is quite easy. Just loop user/meeting_user/meeting_id and also check, that meeting_user/group_ids is not empty (we could discussed, that this last check is not necessary).
If we do it like this, then the autoupdate-service can filter the values. Maybe we could change the restriction mode meeting_user/A that a meeting_user can only be seen, when the request user can see the user and the meeting. See also #970 for this discussion.
Current behaviour:
It is possible for committee admins to get information about meetings they are no part of, if their accounts are part of different meetings
Screenshot:
Reproduction:
The following information is the info I got from my local instance
I started it and unsed the automatically called initial data
I additionally created two committees, 26 meetings, 4 users (1 OrgaAdmin and 1 committeeadmin)
The information from the subscription (committee_manager_account_list:subscription):
The text was updated successfully, but these errors were encountered: