Typo COPY_STATUS_LONGOVERDUE.override permission

I included the fix for this in my commit for
https://bugs.launchpad.net/evergreen/+bug/1331174

Here is the commit

http://git.evergreen-ils.org/?p=working/Evergreen.git;a=commit;h=b7b65232ebd6cbc6f06bfca0ad237b767586d4a6

This setting is working as expected:

 http://git.evergreen-ils.org/?p=working/Evergreen.git;a=commit;h=a00b9a8d4a03b444f2928db3ed7a31d013140582

I'm going to close this bug since the code to fix it is included in the code on https://bugs.launchpad.net/evergreen/+bug/1331174

Can someone please tell me if this fix has been included in a release? We have a customer that has upgraded to 2.10.1 and the problem with the permission persists. One of my technical colleagues tells me that he can't see the proposed fix included at any version. Can someone please clarify?

Hi Fiona,
No, it hasn't been included. I'm not sure why I closed this bug prematurely when the code from the other bug was not merged. I'll reopen it. Taking a quick look at the code, it looks like code from bug 1331174 was included in this branch, which will need to be removed before it can be merged. I can work on that today.

In the meantime, Fiona, the following SQL from the upgrade script can be run on your customer's system to fix the typo:

UPDATE PERMISSION.PERM_LIST SET CODE='COPY_STATUS_LONG_OVERDUE.override' WHERE CODE='COPY_STATUS_LONGOVERDUE.override';

No, it has not. The work moved to the other bug cited in comment #3. That bug has apparently stalled on some issues.

You can read the comments there for more information.

You can also resolve the immediate problem caused by this bug by running the following query in your database:

UPDATE PERMISSION.PERM_LIST SET CODE='COPY_STATUS_LONG_OVERDUE.override' WHERE CODE='COPY_STATUS_LONGOVERDUE.override';

HtH,
Jason

Fiona,

See the discussion on https://bugs.launchpad.net/evergreen/+bug/1331174. I can see from there that the resulting development branch has not been accepted into the master branch, so no, it's not there yet.

Hope that helps!

Chris

As a bit of housekeeping, I've removed the tags from this bug as the pullrequest exists on bug 1331174. If somebody is inclined, it might be a good to idea to just grab the typo fix out of Blake's patches so that this can be fixed independently.

Snagging bug with kmlussier's approval.

I briefly considered trying to standardize on LONGOVERDUE over LONG_OVERDUE, as the former appears more often and matches the stop_fines reason, etc.

Unless anyone else has strong opinions there, I'm not going to attempt that, at least not as part of this bug.

If we keep the focus of this bug to "fix the permission.perm_list entry to match what the code is looking for", I think we'll need an upgrade script that addresses three possible existing database states:

1) no corrective action has been taken, permission exists with id 549 and code COPY_STATUS_LONGOVERDUE.override

2) permission with id 549 has already been updated to have code COPY_STATUS_LONG_OVERDUE.override

3) new permission with unknown id and code COPY_STATUS_LONG_OVERDUE.override has been added, and potentially assigned to users/groups

In the case of 3, users and groups may have been assigned both perm id 549 and the local permission of unknown id.

My goal would be to have an upgrade script that handles the above gracefully, with the end result being that if the user or group had either form of the permission before, they have the one correct permission after the upgrade script runs, and any locally-added permission.perm_list entry is deleted.

+1 to your suggested approach. It's very thorough. Thanks Jeff!

Agreed, that approach sounds sensible.

Working branch for pullrequest consideration is at user/jeff/lp1378829_fix_long_overdue_perm

http://git.evergreen-ils.org/?p=working/Evergreen.git;a=shortlog;h=refs/heads/user/jeff/lp1378829_fix_long_overdue_perm

After this, the only remaining instance of COPY_STATUS_LONGOVERDUE appears in the docs/RELEASE_NOTES_2_5.txt file, which I don't think we actually want to change retroactively.

Snagging this for review and potential pushing this weekend.

Tested the patch with a fresh master, a system upgraded to rel 2.12 from rel 2.10, and an version of master prior to the fix. In all cases, the pg tap tests succeeded and the problem was resolved.

Committed the fix to master, rel_2_12, and rel_2_11.

Thanks, Jeff!