Shelving Location Editor appears to allow staff to see and edit other library's shelving locations

[Jennifer Pringle]

Evergreen 3.5 through 3.8.0

All staff, regardless of permissions assigned, can see the shelving locations for their entire consortium (Administration -> Local Administration -> Shelving Locations Editor). Staff should be restricted to the appropriate locations similar to how the org unit selector restricts what org units are shown in the Group Penalty Thresholds (Administration -> Local Administration -> Group Penalty Thresholds)

Additionally, staff with the following permissions granted at the System or Library level are able to edit all shelving locations in their consortium:
 - CREATE_COPY_LOCATION
 - UPDATE_COPY_LOCATION
 - DELETE_COPY_LOCATION
For some reason when the permissions are set at the Branch level staff are properly restricted to editing the shelving locations for just their branch.

To test this I added the three COPY_LOCATION permissions to an account with the Circulators permission group on a 3.8.0 server with Concerto data. (The Local Administrator and System Administrator accounts have the EVERYTHING permission rather than the individual COPY_LOCATION permissions so aren't great to test this.)

[Michele Morgan (mmorgan)]

I have not been able to reproduce this on 3.7 or 3.8.

I do see that when an action is attempted that is not permitted by the user, the toast reports Update Succeeded, but no change has actually been made.

I tested on the 3.8 community demo server as follows:

Logged in as admin, and, in the User Permission Editor added the following permissions at the System level to user br1bbrown:

 - CREATE_COPY_LOCATION
 - UPDATE_COPY_LOCATION
 - DELETE_COPY_LOCATION

Logged in as br1bbrown, I attempted the following:

Add a shelving location owned by CONS
Edit a shelving location owned by CONS
Edit a shelving location owned by SYS2

For all of these actions "Update Succeeded" was reported, but no updates were actually made.

I was able to successfully add and edit shelving locations owned by BR1 and SYS1 as I would expect.

Could the issue be that "Update Succeeded" is being reported when it actually failed? This in itself is a fairly serious bug IMO, and happens in other interfaces, too. But I am not seeing an issue with the permissions not working as they should.

[Christine Burns (christine-burns)]

I have tested and can confirm when an action is attempted that is not permitted by the user, the toast reports Update Succeeded, but no change has actually been made.

The issue here is that "Update Succeeded" is being reported when it actually failed.

[Terran McCanna (tmccanna)]

Modified title to reflect that the interface allows staff to attempt to edit other libraries' shelving locations, but fails.

[Susan Morrison (smorrison425)]

Adding related bug: https://bugs.launchpad.net/evergreen/+bug/1989972

[Susan Morrison (smorrison425)]

Confirmed on a 3.11-beta test server that the Update Succeeded part of this issue is resolved with the fix from https://bugs.launchpad.net/evergreen/+bug/1808016