upgrading to 2.5+ can break copy templates

[Galen Charlton]

The introduction of floating groups in Evergreen 2.5 changed the type of the asset.copy.floating column from a Boolean to an integer. However, holdings maintenance copy templates (i.e., the staff_client.copy_editor.templates user settings) that predate the upgrade can continue to attempt to set the floating value to true or false.

The effect that if one attempts to save an item record in holdings maintenance after applying such a copy template, the save will fail.

There are various ways to fix this:

[1] Add special logic to holdings editor to detect this and either ignore it or give the user a chance to update the copy template.
[2] During upgrade, munge existing copy templates. One possibility: if the template sets floating to false, remove that field; if it sets it to true, change it to set it to "1", matching the default floating group that gets creating during upgrade.

Evergreen 2.5 and later

[Mike Rylander (mrylander)]

Another possible solution would be to move the floating group functionality out to a new field or table, turn asset.copy.floating back into a bool, and have the checkin code look at the new field. FWIW, this would be my preferred solution, as it would address other potential issues such as reports that expect a.c.floating to be a bool.

[Galen Charlton (gmc)]

Though the genie that's escape the bottle presumably incudes even newer reports that expect a.c.floating to not be a bool.

[Galen Charlton (gmc)]

That's more a call for us all to think about the upgrade consequences this go around, not necessarily a -1 to Mike's idea.

To be clear, Mike - are you thinking of something like this?

asset.copy.floating BOOLEAN -- whether or not the item floats at all
asset.copy.floating_group -- reference to the applicable floating policy

[Mike Rylander (mrylander)]

Aye, and back-patching that to 2.5 to stem the bleeding.

[Rogan Hamby (rogan-hamby)]

Knee jerk reaction - I don't want it going back to bool.

I know that SCLENDS are others have been changing things (rebuilding copy templates), changing things like the CollectionHQ script, etc... a change back means going back to undo what we've spent a few months doing.

[Doug Kyle (dkyle)]

I'll have some work to do either way, and don't have a strong preference, other than knowing how its going to be.

I'm interested in making the changes once a direction is chosen.

[Kathy Lussier (klussier)]

Since 99% of Evergreen libraries are hopefully already on a release that is later to 2.5, should this bug still be open? I expect most libraries that were using floating in their copy templates prior to 2.5 have dealt with this issue in one way or another.