[BUG] Changing an attachment’s parent and note in one save loses the parent change
I can reproduce an attachment-parent update issue in Zotero 10.0.6 on Linux x86-64, both through normal sync with zotero.org and locally with sync disabled. The tests use disposable desktop profiles.
For an existing attachment, changing "parentItem" and its embedded "note" in the same fromJSON() / saveTx() operation saves the note but leaves the attachment under its previous parent. No error is reported.
2. Sync an isolated desktop profile so it has the attachment under A.
3. In one Web API PATCH request, update the attachment’s "parentItem" to B and its "note" from empty to nonempty, with the item’s current version as the precondition. Leave attachment-specific metadata unchanged.
4. Sync the existing desktop profile again.
· Changing only the note saves it correctly
· A second, fresh desktop profile downloads the combined update with the correct parent B and note
For an existing attachment, changing "parentItem" and its embedded "note" in the same fromJSON() / saveTx() operation saves the note but leaves the attachment under its previous parent. No error is reported.
Expected
Both the new parent and the note are saved.Actual
The note is saved, but itemAttachments.parentItemID still references the old parent. The attachment’s JSON after saving also reports the old parent. This persists in the desktop’s SQLite database, it is not just a stale tree display.Reproduction
1. Create two bibliographic parents, A and B, and a linked-URL attachment under A in the online library.2. Sync an isolated desktop profile so it has the attachment under A.
3. In one Web API PATCH request, update the attachment’s "parentItem" to B and its "note" from empty to nonempty, with the item’s current version as the precondition. Leave attachment-specific metadata unchanged.
4. Sync the existing desktop profile again.
Observations
zotero.org returns the new parent B and the new note. The desktop saves the note and the new item version, but still reports parent A. Its SQLite itemAttachments.parentItemID also points to A. Restarting and syncing again does not correct it.Controls in the same test
· Changing only the parent moves an existing attachment correctly· Changing only the note saves it correctly
· A second, fresh desktop profile downloads the combined update with the correct parent B and note
Upgrade Storage