Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Implement "read by source" receipts for journalist replies #889

Open
eloquence opened this issue Mar 6, 2020 · 3 comments
Open

Implement "read by source" receipts for journalist replies #889

eloquence opened this issue Mar 6, 2020 · 3 comments
Assignees
Labels
enhancement New feature or request needs discussion

Comments

@eloquence
Copy link
Member

There is a somewhat obscure feature in the classic SecureDrop experience, where a journalist reply will transition to "read" in the Journalist Interface once it has been deleted by the source:

Screenshot_2020-03-06_15-29-29
Screenshot_2020-03-06_15-29-44

The client should have feature parity with the Journalist Interface, so we should aim to preserve this behavior in the client, or remove the feature altogether. This is distinct from "read/unread" or "seen/unseen" status, which indicates whether a journalist has read a message or seen a document (#187).

@sssoleileraaa
Copy link
Contributor

sssoleileraaa commented Jun 23, 2020

i see this feature now. the journalist interface shows a little checkmark next to the reply to indicate that it was deleted by the source. so really this means "deleted by source." we could be more transparent to journalists in the UI about what it actually means, because it is possible, perhaps unlikely, but possible that the source accidentally deleted the reply and never read it.

@sssoleileraaa
Copy link
Contributor

sssoleileraaa commented Aug 25, 2020

Looks like this is stored as deleted_by_source on the server replies table. If we want feature parity, we would need to allow reply deletion from the client, which modifies how a conversation is displayed. I would argue that we don't want to allow single reply deletion.

@hoyla
Copy link

hoyla commented Dec 16, 2022

User feedback: I'd just like to comment that for our users this feature is not obscure; it's significant – albeit only a necessary, not sufficient, indicator that the source has seen a reply.

Its absence in the workstation sd-app is one of the reasons we are also having to check the old journalist portal at least once daily.

Looks like this is stored as deleted_by_source on the server replies table. If we want feature parity, we would need to allow reply deletion from the client, which modifies how a conversation is displayed. I would argue that we don't want to allow single reply deletion.

Unless I'm misunderstanding your point @creviera , I'm not sure feature parity (between journalist portal functionality and client app functionality) requires that the reply be actually deleted on the client app workstation; just that the reply be shown as having been read by the source. On the journalist portal, replies that have been 'deleted' by sources are still present.

@tina-ux tina-ux self-assigned this Dec 16, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request needs discussion
Projects
None yet
Development

No branches or pull requests

4 participants