Typo COPY_STATUS_LONGOVERDUE.override permission

Bug #1378829 reported by Blake GH on 2014-10-08
This bug affects 3 people
Affects Status Importance Assigned to Milestone

Bug Description


The documentation here says it all:


The screen shot of the GUI complains about wanting COPY_STATUS_LONG_OVERDUE.override but the database only has

COPY_STATUS_LONGOVERDUE.override permission

This simply needs to be altered to be
COPY_STATUS_LONG_OVERDUE.override permission

Changed in evergreen:
status: New → Confirmed
Blake GH (bmagic) on 2014-10-08
tags: added: pullrequest
Michele Morgan (mmorgan) on 2015-03-19
tags: added: signedoff
Kathy Lussier (klussier) wrote :

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

Changed in evergreen:
status: Confirmed → Invalid

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?

Kathy Lussier (klussier) wrote :

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:


Changed in evergreen:
status: Invalid → Confirmed
importance: Undecided → Low
tags: added: needsrepatch
Jason Stephenson (jstephenson) wrote :

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:



Chris Sharp (chrissharp123) wrote :


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!


Kathy Lussier (klussier) on 2017-04-06
Changed in evergreen:
assignee: nobody → Kathy Lussier (klussier)
Galen Charlton (gmc) wrote :

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.

tags: removed: needsrepatch pullrequest signedoff
Jeff Godin (jgodin) on 2017-04-14
Changed in evergreen:
assignee: Kathy Lussier (klussier) → Jeff Godin (jgodin)
Jeff Godin (jgodin) wrote :

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.

Kathy Lussier (klussier) wrote :

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

Galen Charlton (gmc) wrote :

Agreed, that approach sounds sensible.

Jeff Godin (jgodin) wrote :

Working branch for pullrequest consideration is at 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.

Changed in evergreen:
assignee: Jeff Godin (jgodin) → nobody
tags: added: pullrequest
Jeff Godin (jgodin) on 2017-04-15
no longer affects: evergreen/master
Changed in evergreen:
milestone: 3.next → none
no longer affects: evergreen/2.10
no longer affects: evergreen/3.0
Jason Stephenson (jstephenson) wrote :

Snagging this for review and potential pushing this weekend.

Changed in evergreen:
assignee: nobody → Jason Stephenson (jstephenson)
Changed in evergreen:
assignee: Jason Stephenson (jstephenson) → nobody
milestone: none → 3.0-alpha
status: Confirmed → Fix Committed
Jason Stephenson (jstephenson) wrote :

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!

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