Evergreen

volume/copy creator bug "error in stash and close, ancn_id = undefined"

Bug #1075262 reported by Jason Etheridge
6
This bug affects 1 person
Affects Status Importance Assigned to Milestone
Evergreen
Confirmed
Undecided
Unassigned

Bug Description

The volume/copy creator relies on stock rows in asset.call_number_prefix and asset.call_number_suffix for handling blank/empty affixes. These rows are not exposed in the admin interfaces for managing affixes. They assume that the org with id = 1 is the top of the org tree. If this is not the case, then it will break the interface for any org that does not get those blank affixes pulled down during login. An "error in stash and close, acn_id = undefined" alert is the first symptom.

So this is specific manifestation of a more general problem, in that we assume the top of the org tree will have an id of 1 in a lot of places, or that we allow the top of the org tree to have an id other than 1 in the first place.

Off the top of my head, this could affect the -1 row in asset.call_number, the -1 row in the affix tables already mentioned, the context org used by the JSPAC for retrieving org settings when not logged in, the stock Stacks location in asset.copy_location.

-- Jason

Tags: cataloging
Revision history for this message
Jason Etheridge (phasefx) wrote :

Maybe putting a constraint on actor.org_unit where parent_ou can be null only when id = 1 would be a sufficient road block for would-be foot shooters.

Revision history for this message
Thomas Berezansky (tsbere) wrote :

A number of things need to be in specific places for the system to be happy. Some of them make some kind of sense to someone looking quickly. Others don't.

For example, the default "Stacks" location doesn't make sense to everyone (at least not in libraries) and the fact that it has to exist causes confusion at times.

Things like the "-1" bib and call number at least are outside of the normal numbering range of 1+ and thus are obviously special, but many of the others aren't as obvious, especially when people are encouraged and/or expected to be adding and removing entries.

Also, if we are going to add special constraints for some of these I think we may need to add them for others. Like "You can't delete or change the id/owner of the stacks location", preventing deletion of the core statuses, etc.

Revision history for this message
Galen Charlton (gmc) wrote :

I'm not a fan of baking in a strict requirement that the root of the OU tree have aou.id = 1, and not just because I dislike magic numbers. I know of at least one Evergreen system that started off as just a single library system but later added additional library systems -- and that growth of the system was not anticipated from the beginning. What was their root OU got pushed down the tree, and allowing that (along with adjusting ou_type values and a few things that depend on OU depth) is a smaller change than potentially having to touch a lot of tables that refer to aou.id.

Revision history for this message
Jason Stephenson (jstephenson) wrote :

I agree with Galen about not having magic numbers.

Changed in evergreen:
status: New → Confirmed
Tiffany Little (tslittle)
tags: added: cataloging
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.
Subscribing...

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.