Return of the "user can edit themselves" bug

Branch available here: https://git.evergreen-ils.org/?p=working/Evergreen.git;a=shortlog;h=refs/heads/user/miker/lp-1842940-user-edit-restrictions

Thanks, Mike.

As a heads up, arrow functions in AngJS break the test runner.

e.g. .filter(p => $scope.patron.profile.id() == p.id()).

Bah, thanks for the head's up, Bill. I'll force-push a function-y version in a moment.

That's what I get for trying to be like the cool kids...

Existing branch force-updated.

In some cases you want staff to be able to edit their own accounts, e.g. a small library with a single local admin who needs to update the expiry date on their account. This ability should be governed by a permission, like so (building on Mike's branch):

https://git.evergreen-ils.org/?p=working/Evergreen.git;a=shortlog;h=refs/heads/user/jeffdavis/lp1842940-user-edit-restrictions-perm

Thanks, Jeff. I picked your commit, signed off on it, and squashed a minor change into it to fetch the permission for testing. That's back on my branch at:

https://git.evergreen-ils.org/?p=working/Evergreen.git;a=shortlog;h=refs/heads/user/miker/lp-1842940-user-edit-restrictions

One small request: could you add a small message to the tt2 form that tells users that they have insufficient permissions? We had some complaints about the Dojo interface behavior not being very obvious.

Hi Jane,

I've attempted to implement your request in a new commit on the branch linked in comment #6. I'll run it through its paces soon, but I'd appreciate more eyes!

TIA

That's great, Mike! Thanks for adding the messages -- those will really help with troubleshooting.

They look mainly good -- the only issue is that these messages cut off the patron summary on the left side of the screen for me (screenshot attached).

Otherwise, I'm very happy with this, and have a signoff branch here: user/sandbergja/lp-1842940-user-edit-restrictions. I also took the liberty of rebasing that one against master, fixing a small merge conflict, and changing the ID of the new permission.

Thanks, Jane. The best idea I could come up with was to put the alert divs in a container inside the button container and give that alert container css like:

#no-edit-alert-container {
    z-index: 10;
    position: absolute;
    bottom: -200px;
}

That should make them "float" above the content but not extend the height of the sticky bar at the top.

I'm not in a position to push anywhere for testing this morning, unfortunately. Also, UI design is not my ... strongest skill.

Force-pushed a commit for that back to my branch, with your signoffs included.

FWIW, the approach I show above is working for me in testing -- no clipped editor pane, and the alerts float nicely below the buttons. If anyone wants to bike-shed the details of the CSS, or the eventual committer would like to forcibly adjust them, I certainly won't be hurt.