Submission not deleted on disk if deleted via Journalist Interface

[eloquence]

First reported by @rmol here and attributed to AppArmor policy issue #856, but I think it's an unrelated bug.

Steps to reproduce

1. Start the client and log in (run via LOGLEVEL=DEBUG securedrop-client in sd-app)
2. Load Tor Browser in sd-proxy and visit the Journalist Interface and Source Interface; log in there as well
3. Create a new source via the Source Interface and upload a file.
4. Wait for the client to sync.
5. Download the file via the client and wait for the download to finish.
6. Delete the file (not the whole source) via the Journalist Interface

Expected behavior

After the next sync, the file is removed from disk.

Actual behavior

The client appears to never attempt to delete the file. It remains in the ~/.securedrop_client/data directory.

I've tested with both the packaged 0.2.1-deb prod build and master in Qubes, and while I've not applied the AppArmor changes in #866 locally, I don't see any AppArmor denials in syslog, nor any log entries indicating that a deletion is being attempted. In this log you can see the number of submissions decreasing after the sync.

[redshiftzero]

We have logic in storage.delete_single_submission_or_reply_on_disk to handle this, but it looks like it is broken

[eloquence]

Just a note that at least in 0.2.3-deb, I am also observing this issue when the entire source collection is deleted from the JI, not just when an individual document is deleted.

[redshiftzero]

yep that is expected due to in the 0.2.3-deb we use the “delete single submission” method (that is not working) for each item in the source collection (if the deletion was not triggered by the local user)