staff accounts without working locations cause problems

[Jason Etheridge]

Possible solution includes not allowing staff logins for accounts without a working location (at least for workstation-based logins.. use the workstation lib as the context org and check the depth of the STAFF_LOGIN permission).

Can mitigate by spawning the user perm editor after creating a staff user (based on the user having the STAFF_LOGIN permission).

[Jason Stephenson (jstephenson)]

I'd actually like more information about the specific problems encountered. There are places where staff accounts without working locations work just fine.

[Terran McCanna (tmccanna)]

I've noticed that the web client requires that staff have working locations in some places that the xul client didn't, which I'm okay with because it makes sense to me that all staff *should* have working locations.

My only complaint with this is that when something strange happens, it's not usually obvious that it's because of the lack of working location.

[April Durrence (april-durrence)]

We're on 3.3.4 and, due to major overhaul of staff permissions for the consortium, have discovered some staff accounts created by local System Admins have been logging into the web staff client for weeks without any working locations assigned and able to perform multiple functions without them. It is only some activities that seem to check for valid working locations with no notification that the failure (to create a new volume or item, for example) is because no working locations assigned for that branch.

In the past, staff could not log in via XUL without a working location assigned for the branch they were selecting as their workstation. It seems that the web staff client should perform that same check and it would certainly be helpful when a check is performed to add error messages that indicate a function could not be completed because account does not have necessary working location assigned while performing tasks in the web staff client. Not sure how big an ask that is though. :)

[Terran McCanna (tmccanna)]

Noting that with our upgrade to 3.6.1, there are some circulation staff that were able to do work without working locations before that are now unable to work.

I would be in favor of an initial check upon login that gives an error message that indicates a working location needs to be set.

[Terran McCanna (tmccanna)]

Also noting that the new angular staff catalog is one interface that does not work properly without the working location set.

[Jennifer Pringle (jpringle-u)]

+1 to an initial check at login that give an error if there's no working location

[Jennifer Bruch (jbruchpails)]

This is particularly needed for libraries who set up their own accounts via cloning, the working locations do not clone with it and they always forget they need to add them.

PaILS/SPARK would also like to see this implemented.

[Terran McCanna (tmccanna)]

Going to mark this as a duplicate of https://bugs.launchpad.net/evergreen/+bug/1969641 since the work on that one has been tested and signed off.