Comment 9 for bug 1378829

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.