Add support for sending replies to sources

[eloquence]

As a logged in journalist, I want to be able to reply to a source, so that I can follow up on a document or inquiry.

Our assumption is that we will display decrypted messages and replies within the client (#15), so as demonstrated in the messaging prototype, replies should be possible from within the detail view a journalist can obtain for any individual source.

[eloquence]

Just a note that we should be able to support attribution of reply authorship (by username) in the client as a feature in 0.1.0alpha. This is important in case multiple journalists are engaged in a conversation with a source.

For now that username won't be surfaced in the source interface. That may be something we'll want to consider for 0.1.0beta, along with a "Reply anonymously" flow for journalists.

[redshiftzero]

We should locally add the reply to the database such that the UI change occurs immediately for the user, then we should call the API. API callback behavior for the adding of replies should be:

if success: UI change stays in place
if failure: remove row from reply table locally, important from user perspective: move the reply text back to the compose reply area in the UI otherwise they will lose their draft
if failure due to 404: sync API, source is deleted, report that another journalist deleted that source and one can no longer reply

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

One other note from that issue is (nice to have but we can punt this into a separate ticket):

(also: we want the replies list to be up to date, so we should probably sync the API when the user starts typing in the reply field)

[redshiftzero]

as discussed in our meeting today, I've broken the saving-of-failed-replies part of this ticket into #68 so we can make sure we implement the right behavior from the perspective of the user

[heartsucker]

Blocked by #73.

[ninavizz]

Mini-prototype to demonstrate interaction pattern of "Send" functionality (with an alternate treatment for the activity messaging—thoughts, if any, in Gitter?). Lots of time-based tidbits packed-in to the final screens. 99% of this I doubt will make it into Alpha, but putting link to prototype here for as-available finessing for Beta. https://projects.invisionapp.com/prototype/Reply-cjnzmojdb000lzz01w00v0jtc/play/a32f5ac7 /cc @heartsucker @ntoll

[heartsucker]

From chat with @redshiftzero, the quick 'n dirty notes on what an MVP for this needs to do:

1. send reply
2. push to db with is_confirmed = False
3. On success, is_confirmed = True
4. On failure, turn bubble red
5. Ensure db sync doesn't nuke unconfirmed messages (for now)

[heartsucker]

@redshiftzero re: last night's conversation, we said that we were going to use the @proptery collection for a Source to do ordering of messages in the app, but this won't work for unconfirmed replies because there is no filename yet because that is generated by the server. Additionally, we currently set the filename to nullable = False.

I think the best we can do now is to cache the reply in the widget itself and always put unconfirmed replies at the bottom of the message chain. This would cover the situation where a sync happens between reply sent and confirmation.

For example

1. There are N messages/replies in a given thread
   • Thread shows N ordered by filename
2. Journalist makes M unconfirmed replies
   • Thread shows N ordered by filename followed by M ordered by when they were sent
3. API syncs to have N+X messages/replies (none of which are M)
   • Thread shows N+X ordered by filename followed by M ordered by when they were sent
4. Then one of the following happens
   1. Some messages in M fail or succeed or are left pending
      • We mark them accordingly
   2. Some messages M are returned in an API sync
      • If they are un- and confirmed, we remove them and leave the API-generated ones in the thread
      • If their UUID does not appear in the API sync, we leave them alone and appended to the bottom

Out of scope for now is strict ordering of sent messages, but this needs to be added eventually.