Upgrade StorageA collection whose internal ID equals its library's ID cannot be dragged to the library root
Dragging a nested collection onto the "My Library" row normally moves it back to the top level. For one collection in a library this is refused with the no-drop cursor: the collection whose internal ID happens to equal the library's ID. For My Library (library ID 1) that is the collection with ID 1, in practice the first collection ever created in that Zotero database (the IDs are local to each computer's database, so on another computer it can be a different collection).
Steps to reproduce (fresh profile, so that no collection exists yet)
1. Create a collection "First" (in a database with no collections it gets ID 1, the same number as My Library), then a collection "Second".
2. Drag "First" onto "Second" so it becomes a subcollection of "Second".
3. Drag "First" onto the "My Library" row.
Expected: "First" moves back to the top level, like any other collection.
Actual: the no-drop cursor; nothing happens. Dropping "First" onto any collection row works, and any other collection (create "Third", nest it under "Second", drag it onto "My Library") moves to the root as expected.
The same refusal applies to a collection that contains, at any depth, the collection with that ID, and to a group library whose ID coincides with the ID of one of its collections.
Where it comes from
chrome/content/zotero/collectionTree.jsx, canDropCheck, in the zotero/collection branch: for a target row that is a library or a collection, the code refuses "a collection dropped onto itself" (id == treeRow.ref.id) and "into its own children" (draggedCollection.hasDescendent('collection', treeRow.ref.id)). For a collection row treeRow.ref.id is the collection's ID, but for a library row it is the library's ID, so the comparison refuses the collection whose ID equals the library's. Running the two checks only when the target row is a collection (treeRow.isCollection()) fixes it.
Verified on Zotero 11.0-beta.1 on Windows 11: the steps above reproduced end to end in a fresh profile (drag events on the collections tree; "First" is refused, "Third" moves), and canDropCheck called directly on the My Library row answers false for collection ID 1 and true for every other collection.
Steps to reproduce (fresh profile, so that no collection exists yet)
1. Create a collection "First" (in a database with no collections it gets ID 1, the same number as My Library), then a collection "Second".
2. Drag "First" onto "Second" so it becomes a subcollection of "Second".
3. Drag "First" onto the "My Library" row.
Expected: "First" moves back to the top level, like any other collection.
Actual: the no-drop cursor; nothing happens. Dropping "First" onto any collection row works, and any other collection (create "Third", nest it under "Second", drag it onto "My Library") moves to the root as expected.
The same refusal applies to a collection that contains, at any depth, the collection with that ID, and to a group library whose ID coincides with the ID of one of its collections.
Where it comes from
chrome/content/zotero/collectionTree.jsx, canDropCheck, in the zotero/collection branch: for a target row that is a library or a collection, the code refuses "a collection dropped onto itself" (id == treeRow.ref.id) and "into its own children" (draggedCollection.hasDescendent('collection', treeRow.ref.id)). For a collection row treeRow.ref.id is the collection's ID, but for a library row it is the library's ID, so the comparison refuses the collection whose ID equals the library's. Running the two checks only when the target row is a collection (treeRow.isCollection()) fixes it.
Verified on Zotero 11.0-beta.1 on Windows 11: the steps above reproduced end to end in a fresh profile (drag events on the collections tree; "First" is refused, "Third" moves), and canDropCheck called directly on the My Library row answers false for collection ID 1 and true for every other collection.