Hi Jeremy,
I'm going to have to wait to get some input from a developer, but I actually think that part of the issue here might be best defined as a bug.
I tried running a quick test locally in my 2.5 development environment - I created a collection with file-level descendants f1-f15, exported it, modified the CSV so it included new children for import (f16-f30), and then imported it again.
As I was creating the original records in the user interface, the full-width treeview was immediately putting them in the wrong place - and when I tried to drag and drop to rearrange them, I got the following error message in the related job:
Job 2003488 "arObjectMoveJob": Mismatch in current position
I tried rebuilding the nested set, clearing the cache, repopulating the index, and then dragging again, only to get the same error. So I tried changing the treeview to the sidebar - and voila, the items were in the correct order.
Upon import of the additions, the sidebar treeview displayed them correctly immediately - but again, everything was out of order in the full-width treeview:
I have asked a developer to take a look at this thread, and report back on the the treeview code before I file a bug ticket. However, here is what I think is happening:
It seems that the full-width treeview may be using its own sort order, which displays the records in a different order than how they are preserved in AtoM's nested set model (the model used to manage hierarchical information in a relational database). This is why I think I'm seeing the sort order change when the treeview type is changed, and why trying to drag and drop to correct the full-width sort display is producing an error - AtoM's database is saying the record is already there, or at least in a different place than I'm being shown.
From the looks of the image above, it seems the full-width treeview is using an ASCIIbetical sort against the identifier - while the sidebar treeview's manual sort option preserves the order that records are added (which is what you want, in fact). This is just my supposition based on what I'm seeing - I will have our developer review and supplement this thread.
In any case, the short-term solution may be to use the sidebar treeview - not ideal! Otherwise, I'm going to file a bug ticket when I have more information, and hopefully we can get the sort in the full-width treeview to behave the same as the Manual sort in the sidebar treeview, as a starting point (which should also resolve drag/drop errors).
Ideally, the sort options would apply to both trees, so users have options as to how the full-width treeview's hierarchy is displayed - but I suspect this might be a rabbit hole, since there has been a long-standing issue with the sort options even for the sidebar treeview, described in greater detail in this thread:
I suspect we'd have to fix the sort before we'd want to apply it to both trees, and I'm not sure that we'd want to fix it with Option 1 in the thread above, since this would have clearly negative impacts on current functionality. Since the other option is on the expensive side and so far no one has contacted us to sponsor it, I think that for now, we'll have to aim for the easier-to-reach bug fix, and hope we can get that in 2.4.1.
It's possible our developer might have other workarounds for you in the meantime, or local code changes you could make to help address it until we get a fix into an upcoming release. We'll see!
Regards,