Hi, AtoM community.
Thanks to some typos in a CSV import file and some judicious misuse of the CSV importing utility, we've ended up with some archival descriptions that are in some kind of limbo state. Partially deleted? Partially created? We're not sure.
Essentially, having missed Steve Breker's excellent June 21 explanation of why our roundtrip CSV imports were failing to match on legacy ID , we continued working away anyway. One day, we attempted to roundtrip import a set of CSV records where the identifiers stayed the same in the roundtrip, but the titles (the other matchpoint on the fallback matching mechanism) of some objects changed. Some other information was probably changed in many of the records as well, but it is not pertinent to this problem.
While creating the 'delete and replace' update job, we did not choose the 'Skip unmatched records' option, as suggested in the documentation . As a result, when this job ran, most of the incoming records deleted the matching record already in AtoM, but the records with updated titles created new information_objects. The unexpected behavior is that the new information_object ends up in the nested set where the old object was, and the old information_object loses its parent_id and becomes a top-level object -- possibly related to , though we didn't see that note in the job log.
If that were all that was happening, we would probably be fine, because we could identify the objects and delete them from the GUI. But, for some reason, the old (now top-level) information object isn't retrievable by the GUI ('Sorry, page not found') even though the slug still exists and points at the right place. And I think I've found the problem -- these new information_objects have very broken representations in the nested set. Specifically, they all have the same lft and rgt values, those values are each correctly used by another object, and the rgt > lft, which should be impossible.
Since we can identify them all this way, it seems like the easiest way to get rid of them will be to delete them using this  script and the erroneous lft and rgt values as matchpoints. Am I missing something obvious?