Show which journalist sent a given reply

[redshiftzero]

Each conversation in the conversation view is between one source and multiple journalists. We are storing this information and should show on the conversation view which journalist sent each reply.

If a first name and last name are set, they should be used instead of a username.

Acceptance Criteria

Given that there is a conversation with at least one reply to a source
When I view that conversation in the SecureDrop client
Then individual replies to the source should be identified by the journalist's real name (if set) or user name (if not set).

Given that there is such a conversation
When I view it in the Source Interface
Then the author of the reply should not be identified.

User Story

As a journalist, I want to know which reply was sent by which journalist so that I can understand the conversation history.

[See the user stories spreadsheet for current prioritization of this functionality.]

Updated by @eloquence on 2019-06-10 to reflect first name / last name functionality and add acceptance criteria.

[ninavizz]

Static wire demonstrating threading. Sources should NOT see the ID badges, but within the Client journalists should all see their own (upper-right, always; in convo thread when relevant) and their colleague's (in convo threads) ID badges.

Letter in the badge is determined by the first letter of a username, or the person's first name (if/when that separate feature is added). https://drive.google.com/open?id=1GxXbYgQAR7nHlnvXxPFZ_oeA1NmZmf0e

Cheerio!

[heartsucker]

My interpretation of this is that we need a server-side API to pull the list of current journalists. This is a minimum requirement for this feature.

Additionally, this would allow journalists to update their display name (see freedomofpress/securedrop#1592) and have that change propagated to the clients.

[redshiftzero]

so I added journalist_username and journalist_uuid to the reply JSON objects the API provides for this purpose. The sync behavior as already implemented should add journalist users as they are observed to the journalists table

[eloquence]

I've updated the top level comment to reflect the recent addition of first name / last name functionality. Like #411, this is blocked on freedomofpress/securedrop-sdk#87 (SDK support for first names / last names) unless we decide to do a first iteration with just usernames.

The current design spec for the conversation view only reflects display of initials; if we ever want to show more than that (e.g., in a hover state), we'll need a design spec for that, as well.

[eloquence]

Still unclear whether this will make it to beta. Leaving a note here to make sure we carefully reason through the behavior when user accounts are deleted on the server:

• How do we want to deal with loss of attribution information on the server?

• Are there any negative side effects to anticipate due to the use of both IDs and UUIDs on the server, e.g., could there be a situation where a new user account gets an ID of an old one, which would cause historical replies to be incorrectly attributed when they are newly downloaded?

[eloquence]

(Kept on beta but marked as stretch for now, more likely Post-Beta IMO)

[eloquence]

As expected, moved to post-beta.

[eloquence]

This is not quite ready for dev yet, but we've agreed to put our heads together (at least @creviera @eloquence @ninavizz) to finalize the design and implementation plan for a first iteration, as part of the 7/23-8/5 sprint.

[sssoleileraaa]

update: working on a spike to see how this can be split into a couple or few prs, looks like we need to make a few backend changes to make sure a journalist for a DraftReply cannot be None and to pass around the logged in user when authentication changes (instead of just whether or not the user is authenticated) so that we can get the name of the sender of a reply.

can't remember if we discussed hover-overs to show the fullname but that would be a useful thing to add. also: should we change the journalist sender icon to red when the reply fails?

[sssoleileraaa]

you can see how it looks like the journalist is None here when we are dealing with a DraftReply:

i'm at a good stopping point so i'll see if it's just something silly i was doing when i return

[sssoleileraaa]

I created a separate issue for first handling backend changes: #1133

[eloquence]

We (Mickael/Allie/Nina/Erik) discussed the first iteration of this feature in some more detail today. We agreed that the first iteration will only use two colors, the A/1 combination from https://scene.zeplin.io/project/5c807ea562f734bd2756b243/screen/5cba6b2f3367280c23df2be4, and a tooltip for showing the full name. The first iteration should use the A color to identify the currently logged in user (if any) both in the AuthWidget and for replies attributed to that user.

Once that's done, we can resolve this issue, and track further UX changes (more colors, improved hover behavior) in separate tickets.

Still TBD: how to render deleted users in the first iteration.

[eloquence]

For the 8/20-9/2 sprint, we've committed to landing the backend dependencies for this change, including an SDK release (freedomofpress/securedrop-sdk#127), and to get a draft PR for the reply badges functionality up which may not be fully ready for review yet (e.g., handling of deleted users may still be pending).

[sssoleileraaa]

Going to make a draft PR of this branch https://github.com/freedomofpress/securedrop-client/tree/journalist-initials-in-reply until freedomofpress/securedrop-sdk#128 is resolved

[eloquence]

(Removing epic from the project board; we are tracking #1142 as part of the current sprint, which may fully resolve this issue as an MVP, or we may split off some follow-up work before we call it ready for release).

[ninavizz]

Woop Woop! @creviera

<svg width="36" height="34" viewBox="0 0 36 34" xmlns="http://www.w3.org/2000/svg"><style>.a{opacity:0.9;}</style><title>  Group 37</title><g fill="none"><g fill="#FFF"><path d="M16.7 3C10.6 9.9 9.7 9.7 6.7 1 9.8 9.7 9.2 10.4 0 8.5 9.2 10.4 9.4 11.2 3.3 18 9.4 11.1 10.2 11.3 13.3 20 10.2 11.3 10.8 10.6 20 12.5 10.8 10.7 10.4 9.9 16.7 3" class="a"/><path d="M36 16.6C26.5 22 24 21.5 18.6 12 24 21.5 23.5 24 14 29.4 23.5 24 26 24.5 31.4 34 26 24.5 26.5 22 36 16.6" class="a"/><path d="M23.5 0C24.8 3.5 24.5 4.2 21 5.5 24.5 4.2 25.2 4.5 26.5 8 25.2 4.5 25.5 3.8 29 2.5 25.5 3.8 24.8 3.5 23.5 0"/><path d="M7.5 22C8.8 25.5 8.5 26.2 5 27.5 8.5 26.2 9.2 26.5 10.5 30 9.2 26.5 9.5 25.8 13 24.5 9.6 25.8 8.9 25.5 7.5 22" class="a"/></g></g></svg>

[sssoleileraaa]

Update

Before

Currently, on main, all journalist replies are the same color, except when they fail to send (then they are red) or fail to decrypt (then they are gray). Here is an example of the current client:

After

Here is an example of how the PR that closes this issue (ready for review when things settle down for folks and they have time) shows which journalist sent which message, whether the account exists or not (a deleted accounts show the sparkles/stars svg Nina provided here #76 (comment)) and which replies came from the user who is currently logged in (purple badges):

Followup

I opened a followup discussion issue for us to use as a place to capture ideas around how to display errors now that we have reply badges and use colors to mean more than just whether or not there was an error.

[ninavizz]

@creviera I polished the twinklies a bit so they're less-retro and more refined. More twinkly, less sputnik. It's subtle, and may not be worth the late inclusion into the merge, but FYI. Communicating ephemerality is their purpose, not how much I want to move to Palm Springs and live in a cocktaillian utopia.

<svg width="41" height="36" viewBox="0 0 41 36" xmlns="http://www.w3.org/2000/svg"><style>.a{opacity:0.7;}</style><title>  Twinklies</title><g fill="none"><g fill="#FFF"><path d="M16.7 3C10.6 9.9 9.7 9.7 6.7 1 9.8 9.7 9.2 10.4 0 8.5 9.2 10.4 9.4 11.2 3.3 18 9.4 11.1 10.2 11.3 13.3 20 10.2 11.3 10.8 10.6 20 12.5 10.8 10.7 10.4 9.9 16.7 3" class="a"/><path d="M37.7 13.2C27.4 19.2 24.7 18.5 18.7 8.2 24.7 18.5 24 21.3 13.7 27.3 24 21.3 26.8 21.9 32.7 32.2 26.8 21.9 27.4 19.2 37.7 13.2" opacity="0.5"/><path d="M24.5 16C25.8 19.5 25.5 20.2 22 21.5 25.5 20.2 26.2 20.5 27.5 24 26.2 20.5 26.5 19.8 30 18.5 26.6 19.8 25.9 19.5 24.5 16"/><path d="M23.5 0C24.8 3.5 24.5 4.2 21 5.5 24.5 4.2 25.2 4.5 26.5 8 25.2 4.5 25.5 3.8 29 2.5 25.5 3.8 24.8 3.5 23.5 0" class="a"/><path d="M8.5 7C9.8 10.5 9.5 11.2 6 12.5 9.5 11.2 10.2 11.5 11.5 15 10.2 11.5 10.5 10.8 14 9.5 10.5 10.8 9.8 10.5 8.5 7" opacity="0.8"/><path d="M11.5 24C12.8 27.5 12.5 28.2 9 29.5 12.5 28.2 13.2 28.5 14.5 32 13.2 28.5 13.5 27.8 17 26.5 13.6 27.8 12.9 27.5 11.5 24" opacity="0.6"/></g></g></svg>

[sssoleileraaa]

looks great, but just double checking that this is how it is intended to look:

and for comparison, this is what it looks like with the original sparkles:

[ninavizz]

Yup! Do you have a preference? TY for the screenshots, as always!

[ninavizz]

(oof, wanting that "see attachment" and "cannot decrypt reply" to all be italicized and with the em-dashes...)

[eloquence]

"see attachment" is just a test message from a source, not a software message.

[sssoleileraaa]

oh yeah those messages might be confusing too because i was using some old screenshot examples. right now "cannot decrypt reply" is italicized ✔️ but no em-dashes.

[sssoleileraaa]

@ninavizz - for now, I prefer leaving it with the original sparkles until we compare the new one with transparency some more with multicolor badges - it's not guaranteed that the badge color will be blue, so the transparency makes it harder to see a distinct sparkle shape with lighter colors.

[ninavizz]

@creviera Is this release of the PR shipping with multiple colors?? I'd thought it was only shipping with the SD Blue? No colors will be too light for the stars, because they need to be high-contrast enough for the letters to be clearly legible. That's been a big "limiting" factor in the colors I've recommended.

[sssoleileraaa]

good point, i think i was over thinking this earlier. now's a good time to update this in the pr actually, and we can get more people testing it this way.