Desktop,Mobile,Cli: Fixes #11017: Delete revisions on the sync target when deleted locally

[personalizedrefrigerator]

Summary

This pull request fixes #11017 — previously, old revisions would remain on the sync target, even after being deleted locally. It seems that these deleted revisions could also be downloaded on sync soon after being deleted.

Testing plan

Manual testing: I've done only limited manual regression testing:

• (Desktop/Fedora 40): Verified that synchronization starts completes successfully with a local Joplin Server/Cloud instance.

Automated testing: This pull request adds new automated tests:

• 'should delete old revisions remotely when deleted locally': Verifies that revision deletions sync between clients and that new clients don't download deleted revisions.
• 'should not error on revisions for missing (not downloaded yet/permanently deleted) notes': Verifies that old revisions are correctly deleted even if the corresponding item no longer exists.

[laurent22]

The diff is a bit hard to follow. Do you know what was special about revisions which means that they wouldn't be deleted after sync?

[mrjo118]

The diff is a bit hard to follow. Do you know what was special about revisions which means that they wouldn't be deleted after sync?

From what I understand, there were no deleted_items table entries created when deleting the revisions. But the new call to this.batchDelete will create some on all sync sources. I don't follow what all the other changes are for though

[personalizedrefrigerator]

From what I understand, there were no deleted_items table entries created when deleting the revisions. But the new call to this.batchDelete will create some on all sync sources.

That's correct! The other changes include:

• Refactoring to simplify calling batchDelete.
• Removed the SQL query that deleted revisions previously — it has been replaced by batchDelete.
• Added more tests.
• Added logic to prevent revisions for items in a read-only share from being deleted.
  • As commented above, this change needs more testing: It might break if revisions still exist after the original item has been permanently deleted.

[personalizedrefrigerator]

Added logic to prevent revisions for items in a read-only share from being deleted.

Currently, this is done by loading the original item (with BaseItem.loadItemById) and checking whether it's part of a read only share.

This could be problematic: If the original item doesn't exist (e.g. not downloaded yet or permanently deleted), then the revisions can be deleted anyway. I'm not sure how to prevent this — would checking if the parent folder for the revisions is part of a read-only share (with RevisionEntity.parent_id) be sufficient? Would it be possible/make sense to add a share_id property to revisions?

Update: Answered here.