Permissions in the Everything staff permission

[Diane Disbro]

Evergreen 3.9
Chrome

I haven't been able to find out what staff permissions are included in Everything. If I did have that information, it still wouldn't be possible to enable some of the permissions in the Everything group for staff without enabling all of them.

If would be helpful for the group to be dissolved so that the permissions in the group could be interacted with individually.

[Erica Rohlfs (erohlfs)]

Hi Diane,

The way "Everything" was described to me years ago, once upon a time, Everything really did mean all the permissions. Over time, as new development came out, requiring additional permissions, some of those permissions were added to Everything and some were not. To my understanding, this trend continues today. I agree that either the Everything permission should be dissolved or it should include all permissions.

[Jason Stephenson (jstephenson)]

Diane,

Erica's answer is close but not exactly correct. "Everything" is a special permission id (-1). It is not a collection of permissions. It is a single permission.

The standard "has permission" checks include a check for the Everything permission. Some new development doesn't use the standard functions to check permissions and may not work for users with the "Everything" permission. If that is the case, it is a bug and the code should be modified to use the standard permissions check functions.

Hope that helps,
Jason

[Jason Stephenson (jstephenson)]

This is not a bug in my opinion. The "EVERYTHING" permission is simply misunderstood, and what both Diane and Erica want can be done with the current permissions system in Evergreen.

[Jason Stephenson (jstephenson)]

What Diane and Erica want to do can be done in the current permissions system in Evergreen.

A new permission profile group can be created with all of the desired permissions and it can be assigned to users as appropriate.

You do not have to use the "Everything" permission just because it is there.

[Diane Disbro (ddisbro)]

Everything is a single permission - to do what? Is that a question that has no answer? I can remove Everything from a few staff accounts and see what happens.

[Jason Stephenson (jstephenson)]

Diane,

It is a permission to literally do EVERYTHING. It *should* pass every single permission check that there is. If it doesn't, then that is a bug and the permission check should be fixed so that the EVERYTHING permission passes.

I hope that is clear, now.

Cheers,
Jason

[Terran McCanna (tmccanna)]

We only use the Everything perm for testing and for the primary admin account. No other permission groups are allowed this permission because it's too powerful and can be too easily abused (either intentionally or not).

[Diane Disbro (ddisbro)]

What I have heard is that Everything no longer means Everything. New functions have been created over the years that weren't added to the original Everything.

It is interesting to hear from Terran that none of her staff have the Everything permission. That must be where my staff get permission to do simple things like Copy_Checkout since that individual permission has not been granted to them.

Missouri Evergreen is looking at permissions to create a modular group to recommend for member libraries. Sounds like we need to eschew Everything since it doesn't do everything but it does do too much!

[Jason Stephenson (jstephenson)]

Diane,

Yes, those new functions are bugged if they don't work with the EVERYTHING permission.

I agree with Terran that no library staff should have this permission, and neither should the majority of consortial staff. You might want to grant it to one or two global admins for a consortium, or you can use if non-person accounts that are used to run special clean up jobs that might need to do things out of the ordinary via the API code. You can also get by without ever assigning it to anyone.

Jason

[Terran McCanna (tmccanna)]

Yes, if you spend some time setting up your permission groups well then you should rarely ever need to assign any individual permissions to staff members, just the pertinent group(s).

Also, keep in mind that permission groups are hierarchical so any permission assigned to a higher permission group will get inherited, so for example if you have a "Staff" permission group that has Copy_Checkout assigned to it and then underneath Staff you have "Circ Desk" and "Local Admin" then both of those would automatically inherit the Copy_Checkout permission.

In PINES we have two main categories - Patrons and Staff. Under Patrons we have a number of different patron types so we can have different circulating rules and expiration dates for different groups. Under Staff we have it broken down into Circulation (which has different levels below it), LocalAdmin, Cataloging (which different levels below it), and Acquisitions (also with different levels below it). If a staff member is given a Circ1 account then they inherit all permissions that have been granted at both the Staff and Circulation levels.

[Andrea Neiman (aneiman)]

As I understand it, EVERYTHING is not consulted currently with the usr_has_perm_at function - see my lightning talk slides here:

https://docs.google.com/presentation/d/1b5ijwBl2pvvYRPs-cYu1qRxiALDKxHZNPRwXYS8KmsQ/edit?usp=sharing

This might account for the lack of everything in EVERYTHING.

Slides 7 & 8 explain why usr_has_perm_at doesn't look at EVERYTHING and what possible paths to that might be, to wit:

* Identify where usr_has_perm_at is in use, and add a separate EVERYTHING check to those areas; or
* Teach usr_has_perm_at to check EVERYTHING but do something reasonable (i.e., not dump all that data).

I'm happy to open a wishlist bug for one or the other of those approaches, if there's a consensus as to which is better.

[Jason Stephenson (jstephenson)]

Andrea, it would be fine for you to open a separate bug based on your comment #11. We can have an argument, er discussion, over there on how best to fix it.

[Andrea Neiman (aneiman)]

Behold bug 2024863