Under certain conditions (can't reliably replicate, but more on this below) archival objects are failing to move to the desired locations when using "Enable Reorder Mode" (drag/drop, move pulldown, and copy/paste).
Looking at the database, each you attempt to reorder an archival object and it doesn't appear to move in the staff interface, the archival_object's position value is actually incrementing up (or down) in line with what you've told it to do (e.g. move up or down), but that number is not going high enough (or low enough) to actually accomplish the move. But, the position value IS changing. If the user attempts the move a few more times to get the value to rise high enough (or low enough) to actually move it to the correct spot it will eventually move since the position value is changing (albeit too little at once).
Notes regarding when it happens:
Haven't been able to replicate on a brand new database, only on existing databases that were migrated in from AT.
Issue appears to be hit or miss. If you have a resource record open and encounter the issue once, it seems incredibly more likely that it will occur again. If a record is open and you do not encounter this issue initially, it seems unlikely that it will be encountered.
This issue is a lot less likely to occur if the record is created as a child, than if it created as a sibling. This is not a guarantee that you won't encounter the issue, but it seems to be slightly more reliable than the other option.
The bug seems to happen more when the record created is the child of earlier/migrated record, than a brand new record, though I see nothing in the database to indicate why this would be the case.
We have a very similar experience to what Lora and Chris have reported. Some additional points:
We are working with a database in which the resource record was migrated from a prior (non-AT) source, but all of the archival objects have been created in ArchivesSpace, so if this is a migration issue, it isn't specific to AT and only requires the resource record to have been migrated.
In addition to the error occurring more often the further the objects are moving (as I believe Lora was reporting), moving larger numbers of objects increases the chance of error.
Sometimes refreshing the page shows the objects have moved and the reorder moved is just stalled, but most of the time the objects do not move.
We're currently using reorder mode mostly for moving groups of child archival objects to become siblings of the parent object. So if there is a difference between records created as children and as siblings, it seems to run counter to what Lora reported.
At Williams, we've been experiencing the same kind of stalling Chris describes.
Rather than clicking "disable reorder mode," we've been leaving the spinning wheel for an arbitrary number of seconds (5-15?), then refreshing the page.
We have consistently found that after refresh, the moved items appear in their new location.
As Daniel noted, moving large groups of items, or small numbers of items in a collection with several hundred to several thousand items at the same level of description, makes the error more likely.
These observations are all anecdotal – we haven't done comprehensive testing locally to figure out exactly what kinds of scenarios create this problem.
At CWRU we are experiencing something similar - we are having trouble adding and then re-ordering new records in EAD imported from the OhioLink factory tool. We have fixed issues with this record that we see in all the EAD that we import but this is a new one; our new object just won't re-order automatically when created as a sibling or a child and will only move a level above or below it's sibling in re-order mode.
This issue seems to have been cleared up with the recent AS upgrade - everything working fine for the problems we had targeted at CWRU.
Tentatively labeling this as fixed since I cannot reproduce in the 2.7.0 test environment. Unfortunately, I don't know if I’ll have the time to do a local build and test by removing the data in parent_name as detailed in the pull conversation.