Web Client Allows Register Workstation with Org_Unit that Can't Have Users

Marking this Confirmed, a few observations when I tested this, though:

When a user registers a workstation that was not previously registered, the choices in the org_unit dropdown are appropriately* those related to the user's working location and the user's depth for the permission REGISTER_WORKSTATION. I am not seeing org_units in the dropdown that do not allow users.

However, when a user logs into an already registered workstation, all org_units are displayed in the dropdown, including those that don't allow users.

Also, in a stock installation, staff users get REGISTER_WORKSTATION at the Consortium level by default. This did not seem to affect the xul client, but does apply in the web client as noted above.

*Also see related bug 1807427

See also bug 1648922.

It looks like the typeahead changes for bug 1511742 caused this regression in behavior. I reverted the 3 commits from that branch and only org units that can have users showed up in the workstation registration drop down.

I have a potential patch for this one. I'm just waiting on some testing and feedback from local users. There may also be some more work required to address Michele's concerns in comment #1. My fix so far just restores the hiding/disabling of ineligible organizational units.

Here's a branch with a single commit to fix the typo in the template for the workstation registration page. This typo prevented the disabling of org. units in the drop down. This change does not address any other issues raised by Michele in comment #1.

https://git.evergreen-ils.org/?p=working/Evergreen.git;a=shortlog;h=refs/heads/user/dyrcona/lp1802757-fix-menu

I have reassigned myself and removed the pullrequest tag. I want to see if I can get the hide test to work. What I'm seeing is the full list of locations with ineligible locations disabled. I'd rather that the ineligible locations just not show up in the list.

I'm not sure if hiding them is ideal; I think it would be best to have a consistent org tree everywhere that staff can see one (barring any custom org trees though that's opac-only). I can see where a very long list with few options could be irritating but there is type-ahead search / autocomplete.

In that case, I'll leave it alone.

There is a hidden-test specified, but I've seen inconsistent behavior where it sometimes works and sometimes doesn't. I suspect a bit of a race condition with permission lookup.

I've put the pull request tag back on. If anyone wants to remove the hidden test, I wouldn't object at this point.

I want to add that I disagree with not hiding inoperable locations. There's no point in showing the user something that they cannot use as it is just clutter. I don't buy the consistency argument.

I am capitulating in this specific case, however.

I would agree with Jason that hiding ineligible locations would be preferable. Showing the user a list of 76 org units (just as a random example :) ) when there are really only one or two choices that apply just doesn't make sense.

I also don't agree with a consistent org tree everywhere. Org units are multipurpose, they have different attributes based on their type, and also have different applicability to the logged in user. Staff users have working locations, and permissions at certain depths from those working locations. It's frustrating for staff users to constantly have to choose the their org unit from a long list when Evergreen should know that most of the choices aren't possible based on their login and permissions.

Ideally any display of the org tree should be tailored as much as possible to where and to whom it's displaying. If a user can't register a workstation at an org unit that can't have users, it should not display as a choice. Similarly, if a user doesn't have permission to register a workstation at a given org unit, it should also not display.

Sorry for the rant, I'll try and find some time to take a look at Jason's patch.

Fwiw, I agree with Jason S. and Michele. I think Michele's point about org units showing based on users' working locations is spot on. In this case I think hiding ineligible locations *is* actually being consistent, in that it's consistent with the idea of hiding orgs that the user doesn't have access to.

The code is there to hide org units based on the user's permissions and whether or not the org units can have users. It doesn't seem to work consistently for me. I'll wait to take this bug back to see if I can fix that pending anyone looking at it or just saying, "Please do."

Thanks for the explanation Michele; I could get more behind a system where you're only shown those orgs where you have a working location set. I initially envisioned this as the whole org list but with the CONS and SYS levels removed. Sorry if I misunderstood your intent earlier Jason, that sounds worth pursuing.

All right, then. I'll take this one back to see if I can get the hidden test to work consistently. In that case, the disable test will be unnecessary.

I've rebased the original branch on master, fixed the bug number in the branch and commit messages, and added the pull request tag.

There is still a typo in Open-ILS/src/templates/staff/admin/workstation/t_workstations.tt2 that my branch fixes. It mostly resolves the issue. We've been using this patch at CW MARS for a year, now.

I think the other issues should be resolved in other bugs, and the working location issue, I believe is mentioned in bug 1807427.

The rebased branch is here:

https://git.evergreen-ils.org/?p=working/Evergreen.git;a=shortlog;h=refs/heads/user/dyrcona/lp1807257-fix-menu

I have tested this code and cannot sign off as is. The main issue is fixed - I cannot register a workstation with an Org_Unit that Can't Have Users, but based on previous comments I believe these other two issues are also meant to be addressed.

1. The ineligible locations still show in the drop down
 - I believe these are supposed to be hidden as per previous comments

2. The Workstation registration shows user's Home Library as default choice instead of working location
 - I used br1sbrock (changed home library to br2) when I tried to register a workstation the default was br2
 - this issue has it's own bug report https://bugs.launchpad.net/evergreen/+bug/1807427