Add support for deleting entire sources

[eloquence]

As a journalist, I want to be able to delete all files and messages associated with a source, so that I can reduce risks for the source and keep the number of submissions manageable for myself.

As shown in the "hamburger" menu of the messaging prototype, we should support deleting an entire source from the server, which would also delete it from all clients once they synchronize. It must be made clear to the user that deleting an entire source will prevent that source from logging in with their codename.

[eloquence]

One idea under consideration is to introduce an in-between "trash" state, to reduce the potential confusion from suddenly disappearing sources. In most cases, sources would be moved to the trash before being deleted. Emptying the trash might require administrative privileges and/or happen automatically after an expiry window.

For the first iteration, that is not a must-have feature, but I'm flagging it here; ideally, we have resolved that question before implementation begins, so that we can develop the feature with the end state in mind.

[redshiftzero]

For the purposes of syncing (#5), which is closely related to this, we'll proceed with the simplest variant, which is syncing with the server without a trash workflow. This will mean that if a source is deleted either on a client or on the server, after sync it's gone everywhere. I'm noting this in case we decide as part of this ticket (or a followup) to add such a trash workflow, the sync logic will need to be updated.

[redshiftzero]

some implementation notes from the sync discussion in #51:

important: for all the deletion actions, we need to be able to rollback. so we need to first update the UI and then only actually delete the item when we have confirmed the deletion on the server. implementation-wise this means we need to add a column for is_marked_for_deleted on the reply, submission, and source objects. the “delete” action locally would just be: marking source as deleted in the database. the UI should only display rows in each table that have not been marked as deleted.
if success: UI change stays in place. now we carry out the deletion of both the row and the files on disk.
if failure: mark the row as not marked for deletion, display to user that an error occurred deleting the object “try again" and update UI to reflect local db
if failure due to 404: sync API, object is deleted, report the object was deleted to user

• decide on synchronization strategy when pushing to servers #51 (comment)

[ultimatecoder]

I am working on this at #78 The work is in progress. Will update here and at the PR as soon as I am done. Thanks!

[ninavizz]

Hi @ultimatecoder! This is the clickable prototype to demonstrate Delete functionality for Beta. Pls minimize as necessary, to fit to Alpha scope. https://invis.io/EUOVALO94RZ

My assumption is that most of what will make it into Alpha, will be limited to button actions, button labels, and text composed for dialogs. Yep, the "x" instead of a contextual menu on each individual file as the GUI control there, is new. If changing that from how you have it now is a lot of work, then don't worry about matching the "x" for Alpha.

"Export" from the contextual "• • •" menu at the top-right corner of the message pane, is not in scope for Alpha—but is shown in these. FYI.

I'll be online ~9am, and will check Gitter once I'm up and with coffee. Feel free to ping with questions! With Alpha being so limited in scope and @ntoll and @heartsucker being in European timezones, however, I expect they could provide you with better/quicker answers than myself.

Thank you, again, Jaysinh! :)

Nick/Erik: I trust your judgement(s) on how to best get essential things into Alpha to meet the release's goals. Being super-duper user-centric, I appreciate to be far lower on the list than DONE! :)

[ninavizz]

Follow-up to discussion in Sprint planning: @redshiftzero @eloquence in my initial-stab of thinking through user-facing activity messages (for this and other things), I hadn't factored-in TOR things (beyond "everything will take a little longer") or all the API pings.

Would love to learn what all these steps are for deletion and other major user actions, to establish a consistent IFTT schema from which to pattern Client-wide user-facing language and timing of what's shown when. The "Delete Source" task sounds far more complicated for the Client than I'd anticipated, and seems like a great place to start.

Do NOT want to distract from getting Alpha out the door on time, but would love to do this properly to generate a messaging template for Beta. Thoughts?

[eloquence]

For the purposes of the alpha, we should go with the simplest possible implementation, and only support deletion at the source level.

In terms of the "server operation fails / must roll back client state" scenario, I don't think it is unreasonable for this operation to block the whole client until it is successfully performed (and only then perform deletion on the client), certainly for the alpha. By "blocking" I mean showing an ugly modal window for now indicating that the operation is in progress, which in turn would make it impossible for the user to initialize any other actions at the same time.

If that doesn't in fact simplify implementation, then I don't see an issue with going with the rollback approach.