staff users can edit their own accounts

[Chris Sharp]

Following up (over a year later) on the IRC discussion at http://irc.evergreen-ils.org/evergreen/2014-02-27#i_72963, 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()) && patron.id() != openils.User.user.id()) {
        // 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)]

And, that is fixed in this branch:

http://git.evergreen-ils.org/?p=working/Evergreen.git;a=shortlog;h=refs/heads/user/csharp/lp1446860-staff-can-edit-themselves

[Thomas Berezansky (tsbere)]

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

to:

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())) || patron.id() == openils.User.user.id()) {

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)]

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

[Ben Shum (bshum)]

Setting review milestones appropriately.

[Jeff Godin (jgodin)]

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)]

Jeff,

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)?

Thanks,

Chris

[Jim Keenan (jkeenan)]

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)]

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)]

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