Show all motions for meeting admins

[rrenkert]

Current behavior:
If a motion workflow has a state that has the restriction set to is_submitter, motions in this state are not visible to meeting-, orga- and superadmins.

Wanted behavior
To be able to handle motions (e.g. sort in call list) the motions should be visible to meeting admins (this should include orga- and superadmins)

[ostcar]

This is the current rule:

openslides-autoupdate-service/internal/restrict/collection/motion.go

Lines 15 to 24 in d94e9bc

	// The user can see a motion if:
	//
	// The user has motion.can_see in the meeting or
	// for one of the motions in `motion/all_derived_motion_ids` the user has motion.can_see_origin in the corresponding meeting
	//
	// and for one `restriction` in the motion's state `state/restriction` field:
	// If: `restriction` is `is_submitter`: The user needs to be a submitter of the motion
	// Else: (a permission string): The user needs the permission
	//
	// and - for amendments (lead_motion_id != null) - the user can also see the lead motion.

Would it be ok, that a user with the permission "motion.can_manage" can see all motions? This would include all admins.

[MSoeb]

I don't think, that this would help, because in the workflow we can limit the motion access even to can manage motion. If we would use can manage motion in general to see all motions unlimited, we won't need this restriction in the workflow anymore.

Does somebody know, how this was handled in previous OpenSlides versions? I would suggest to to find a solution from this perspective and adopt it to our current permission system.

[rrenkert]

I would prefer a solution with checking OML (CML with #1180) and meeting-admin.

[ostcar]

I would prefer a solution with checking OML (CML with #1180) and meeting-admin.

This would be possible. At the moment, there is only one place in the restricter, that uses this technique. In the meetin_mediafile-collection, there is the rule:

openslides-autoupdate-service/internal/restrict/collection/meeting_mediafile.go

Line 15 in 58c094f

// The user is an admin of the meeting.

This actually checks perm.IsAdmin(), which returns true for members of the admin-group, the super- and orga-admin and will be soon true for committee-admins in the hierarchy.

It would be easy to implement. But since we currently only use this technique at one place, it seems like some sort of an exception. At the moment, the permissions are handled via the permission strings. This will be a step in another direction, what could lead to confusion.

The classical way would be to create a new permission "can see unpublished motions". This permission could be configured at will. I would not be a fan of this permission, since it is to specific.

In conclusion, I don't have a final opinion on this.

Maybe @Elblinator knows what is best from a user perspective?

[Elblinator]

I personally agree with @ostcar

Would it be ok, that a user with the permission "motion.can_manage" can see all motions? This would include all admins.

Yes, this is in my opinion exactly what the admins (and the people who can manage sth) should be able to do. That you are able to exclude the people who should be able to manage the motions is borderline dangerous.
Which we now saw in a real life example.

We can aquire why they make the restrictions to only submitters and not "can_manage", but I would guess that they didn't know better. There are a lot of technical restrictions and side-effects and I think they didn't think about it.
Just to be clear: They had motion without a submitter in the state that only submitters can see them

My proposal:
Give everyone with motion.can_manage rights the right to see the motions. => that's what the people IMHO expect if they are able to manage the motions
And in the client: remove the option "Can manage motions" and add to the help-text that people who can manage motions are excempt

[ostcar]

One argument against that is, that the user of OpenSlides has to trust the meeting-admins. For example in a city council, the mayor probably has manage-permissions. Maybe a member of the council wants to create a motion and share the draft with other members before sending it the to mayor.

But in this situation, they will probably use another tool to create the motion anyway (I would). So I don't think this is a relevant feature and the motion.can_manage solution is the best fix.

[rrenkert]

I think the solution with motion.can_manage has to wide impact.
The restriction is_submitter would then be a is_submitter or has motion.can_manage permission with no possibility to exclude groups with motion.can_manage.
In a discussion with @MSoeb we came to the conclusion that having this granularity would be good and excluding groups with motion.can_manage is a usecase.