staff users can edit their own accounts

Bug #1446860 reported by Chris Sharp on 2015-04-21
This bug affects 3 people
Affects Status Importance Assigned to Milestone

Bug Description

Following up (over a year later) on the IRC discussion at, I have discovered that the triggering issue for that discussion has not been fixed in Evergreen. I applied a patch to PINES at the time and never followed up with a bug report. In any case here it is.

In this chunk of code in Open-ILS/web/js/ui/default/actor/user/register.js:

    if(!patron.isnew() && !checkGrpAppPerm(patron.profile()) && != {
        // we are not allowed to edit this user, so disable the save option
        saveButton.attr('disabled', true);
        saveCloneButton.attr('disabled', true);

The current logic is "Disable the Save button if the following is true:

1) the patron is not new

2) the editing user lacks the permission to edit another user with this user's permission profile

3) the patron ID does not equal the editing user ID

However, as Mike mentions in the IRC discussion, the logic of 3) is reversed from what it should be.

Evergreen 2.7.2
OpenSRF 2.4.0
Ubuntu LTS
PostgreSQL 9.3

Chris Sharp (chrissharp123) wrote :
tags: added: pullrequest
Changed in evergreen:
importance: Undecided → High
assignee: nobody → Chris Sharp (chrissharp123)
milestone: none → 2.7.5
Thomas Berezansky (tsbere) wrote :

I don't think the new code is actually improving things. It changes the check from:

The patron is not a new patron, the editor can't edit the patron's group, and the editor is not the patron being edited


The patron is not a new patron, the editor can't edit the patron's group, and the editor is the patron being edited

The end result basically means "never disable the save button unless you are editing yourself".

For what the proposed "intent" is (and I am not sure about that right now) I think the code would need to look like this:

if((!patron.isnew() && !checkGrpAppPerm(patron.profile())) || == {

Which becomes:

The patron is not a new patron, the editor can't edit the patron's group, OR the editor is the patron being edited regardless of the previous two.

Chris Sharp (chrissharp123) wrote :

Thanks, Tom! I have corrected the issue and pushed to the branch.

Ben Shum (bshum) wrote :

Setting review milestones appropriately.

Changed in evergreen:
milestone: 2.7.5 → 2.8.1
status: New → Confirmed
Jeff Godin (jgodin) wrote :

Commenting because there was recent mention of this being merged as-is:

It's worth noting that this is desired behavior for some libraries, and that the working branch is only a UI-side change -- it does not make changes to the underlying API.

Chris Sharp (chrissharp123) wrote :


Is that just a "noting for the record" comment, or are you suggesting a change (such as a YAOUS or a lower-level-than-JS modification)?



Jim Keenan (jkeenan) on 2015-06-10
Changed in evergreen:
assignee: Chris Sharp (chrissharp123) → Jim Keenan (jkeenan)
assignee: Jim Keenan (jkeenan) → nobody
assignee: nobody → Jim Keenan (jkeenan)
Jim Keenan (jkeenan) wrote :

When I tested this on June 10, 2015, in a sandbox (Bug Squashing Day), I experienced the following two things:
1. I was logged into the staff client as the System Administrator and the System Administrator could not alter the system administrator's account in the patron edit screen. The Save button was grayed out and remained grayed out when I tried to change any of the fields.
2. when I left the patron edit screen, a pop-up appeared letting me know there might be unsaved information (but I had no way to save it so I could ignore).

I know this is probably not much help but I wanted to note it.

RASHMA KUMARAN (rkumaran) wrote :

Verified in Evergreen 2.8

Logged in as admin/...

1. Retrieved Admin account and Click Edit tab to check if any changes can be applied. The Save button is disabled(greyed out) and does not allow any changes to be made.

2. Retrieved another patron account and Click Edit tab to check if any changes can be applied. In this case, changes can be applied with Save button.

Ben Shum (bshum) wrote :

Alright, this lingered long enough, pushed to master, rel_2_8 and rel_2_7.

Changed in evergreen:
status: Confirmed → Fix Committed
assignee: Jim Keenan (jkeenan) → nobody
milestone: 2.8.1 → 2.8.2
Changed in evergreen:
status: Fix Committed → Fix Released
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers