Removed copy tags are not removed

[Nathan Eady]

Steps to Reproduce:
 1. Pull up an item record that has obsolete copy tags you want to remove.
 2. Click edit.
 3. Scroll down.
 4. Click the Copy Tags button.
 5. Click the Remove button.
    The copy tag appears to be removed. (This is temporary.)
 6. Click Ok.
 7. Click "Save and Exit", to save the item record.
 8. Refresh/Reload the OPAC view, to see whether the copy tag is still showing.
 9. Repeat steps 2-4, to check whether the copy tag is still present.

Expected Results:
The copy tag is removed.
Failing that (e.g., if a permissions issue prevents removing it),
there should at least be an error message indicating the problem.

Actual Results:
The copy tag is still showing on the OPAC view after refresh and has also
reappeared in the copy tag editor. There is no error message.

Versions &c:
Evergreen web staff client, Evergreen Version 3-0-8, cool-cat.org
Google Chrome Version 66.0.3359.181 (Official Build) (64-bit) on Devuan ascii.

Additional Information:
Regarding permissions, our consortium contact at OhioNet reports:
"As was suggested during our conference call yesterday, I've added the
ADMIN_COPY_TAG permission at the system level to the Circ. Admin
group. I also checked to confirm that Circ. Admin had the UPDATE_COPY
permission at the system level and they do. After doing so I created a
staff account with Circ. Admin permissions, worked through your
procedure, and experienced the same behavior. I was unable to remove
the copy tag. Elevated all permissions to the consortium. I was still
unable to remove the copy tag using the procedure that you described.
There may be a customized file in COOL's directory path that's causing
an issue or this could be bug."

[Beth Willis (willis-a)]

E.G. Web Client 3-0-9

[Beth Willis (willis-a)]

Confirmed also in EG 3-2-0

[Jordan Woodard (jwoodard)]

Still an issue in EG 3-2-3

[Jason Boyer (jboyer)]

Can any of the affected locations pull the evergreen / postgresql logs from a failed attempt at removing a copy tag? I'm wondering if it's possible that a change to some database triggers may have been missed that prevents these tags from being deleted.

[Geoff Sams (gsams)]

I recently had a chance to test this out on my own system and pull log info. We are running 3.2.3 at the moment.

Postgresql log:http://paste.evergreen-ils.org/10048

osrferror log: http://paste.evergreen-ils.org/10049

It seems to be having a problem with evergreen.asset_copy_tag_copy_map_copy_inh_fkey()

[Felicia Beaudry (fbeaudry)]

Still an issue in 3.3.3

[Mike Rylander (mrylander)]

Geoff, can you paste the output of

\d asset.copy_tag_map

It looks like the fake foreign key constraint against asset.copy is firing on delete in addition to insert and update. It should not be, though. That was supposed to be fixed in commit bdcb8b6acf829940e1ebbef0feabd2c60461d082, so perhaps local customization of upgrades missed that?

[Galen Charlton (gmc)]

I've tracked down the problem: under certain upgrade scenarios, the asset.copy_tag_copy_map table can end up with two instances of the fake FK trigger, including one that still fires on DELETE:

    inherit_asset_copy_tag_copy_map_copy_fkey AFTER INSERT OR UPDATE ON asset.copy_tag_copy_map DEFERRABLE INITIALLY IMMEDIATE FOR EACH ROW EXECUTE PROCEDURE asset_copy_tag_copy_map_copy_inh_fkey()
    inherit_copy_tag_copy_map_copy_fkey AFTER INSERT OR DELETE OR UPDATE ON asset.copy_tag_copy_map DEFERRABLE INITIALLY IMMEDIATE FOR EACH ROW EXECUTE PROCEDURE asset_copy_tag_copy_map_copy_inh_fkey(

Patch forthcoming.

[Galen Charlton (gmc)]

A patch is available in working/user/gmcharlt/lp1786100_fix_actcm_inh_fkey / https://git.evergreen-ils.org/?p=working/Evergreen.git;a=shortlog;h=refs/heads/user/gmcharlt/lp1786100_fix_actcm_inh_fkey

[Rogan Hamby (rogan-hamby)]

I've tested the second part of the test plan, a system without the DELETE trigger part and sign off is here: user/rogan/lp1786100_fix_actcm_inh_fkey

I also manually changed the trigger to include DELETE and tested it again FWIW.

[Galen Charlton (gmc)]

Pushed to master and rel_3_6. Thanks for testing, Rogan!