Secondary Permissions do not respect Application Permission Field

Tested in 3.10 and experienced the same behavior.

We are experiencing this in 3.11.2 as well.

Changing to wishlist because, while I understand the desire, the Group Application Permissions mechanism is specifically intended to restrict creation and modification of a user based on their Profile Group field.

I think either a secondary-group focused mechanism, or a separately permission-protected library setting (or, more realistically to reduce the complexity of the logic for the user, a global flag) that tells the system to treat secondary groups the same as the Profile Group, will be needed.

So currently, if the highest level permission group is the primary, the editing will be restricted appropriately?

I think a global flag will work for us. We have separate permission groups for job duties, so we use the Secondary Permissions often. The higher permission groups that require support intervention are often paired with lower permission groups that don't require support intervention.

Terran- correct. Say a staff member has a circclerk permission group (support is not required to assign) and original cataloger (support has to assign once they take the certification quiz). If the original cataloger is in the primary it will block, but if the circclerk is in the primary, non-support staff can edit. We see it happen most often in the user buckets.