Submission categories

[tildelowengrimm]

At CPJ, there are multiple teams who check SecureDrop for submissions. Other newsrooms may have a similar situation — different teams or authors who are not particularly interested in submissions meant for each others. CPJ staff would very much like it if there were a way for a source to pick a topic or department for their submission: metadata that is visible to journalists checking the document interface.

In a more advanced version, it would be best to be able to assign users to these groups so that someone only sees relevant material when they log in, and don't have the opportunity to mark other teams' submissions as read or delete them (more from the perspective of practical logistics than security).

[garrettr]

Great idea! This should be relatively straightforward to implement. You'll need to add some way to manage these categories (and access control based on categories) to the Admin portion of the Document Interface.

[taravancil]

I'm working on this! I'll submit the finished PR tomorrow as my contribution to the hackathon.

A few questions as I finish up:

• Should non-admins be able to create new categories or add/remove them from submissions? I've reserved these capabilities for admins, but I can easily change that.
• I'm thinking about adding the ability to make a category private, so that sources can't see the category or add it to submissions. I imagine this will be useful if an organization uses categories like "high-priority", "Journalist Name", "team A", etc. Good/bad idea?

[garrettr]

Let's focus on MVP for this initial implementation, and file follow ups for more complex functionality if desired. As described, the goal for this issue appears to be:

• A source chooses a category or categories for their submission from a drop-down menu when they submit.
  • You should choose early on whether a submission can have one or multiple categories, since this defines the underlying representation in the database. Depending on this choice, the Source UI should be a <select> or a list of checkboxes.
• The categories are free-form text labels. Categories can be created, edited, and deleted by admin users on the Document Interface.
  • You will need to consider and document the correct behavior for submissions if one, several, or all of their categories are deleted.
• There should be always be a default/uncategorized category available.
• Journalist users will only be able to see submissions from a subset of categories. Which journalists can see which categories should be configurable by admin users on the Document Interface. This forms the basis for access control within the Document Interface.
  • Note that all submissions will still be encrypted with the same offline submission key - access control occurs at the level of the Document Interface, not at the cryptographic level. This is actually necessary to achieve category agility. It may be desirable to add flexibility at the cryptographic layer for various reasons, including access control, but that is outside the scope of this issue.

[taravancil]

I'm very close to MVP, so I'll hold out on adding public/private categories until others have had a chance to review my code and decide if it would be a valuable feature.

You should choose early on whether a submission can have one or multiple categories.

In my implementation, a Source can add multiple categories to their submission. Admins can later add/remove categories from the submission.

There should be always be a default/uncategorized category available.

Only admins can see uncategorized documents.

Journalist users will only be able to see submissions from a subset of categories. Which journalists can see which categories should be configurable by admin users on the Document Interface.

This feature is in place. Admins can edit a journalist's categories on the same page they can change passwords. Journalists can only see the subset of documents in categories they've been granted access.

PR coming after I write some tests!

[garrettr]

@taravancil We're tracking work for the hackathon on Trello, and chatting about stuff on Gitter. Check out this Trello card for info on joining us, if you want. I'll go ahead and create an in-progress Trello card to track this issue for you, since I know you're already working on it 😄

[eloquence]

Closing in favor #1356