Complete visibility settings: allow individual IncomingMessages to be hidden

[sebbacon]

Some models have a "visible" flag, which was an incomplete feature from some time ago. Notes from Francis:

*** this needs either removing or finishing, it is half done. Has the
database entries but doesn't use them yet.

Move comments to use new system first
Show message to signed in user that others can't see this part
Make sure hidden things don't show in search snippets
in models/comment.rb: # So when made invisble it vanishes
Remove comments visible

[frabcus]

I think it is that comment has a boolean called "visible" and there is a special GUI for hiding comments.

Often though admins want to hide other individual objects - like incoming and outgoing messages (the use cases being things like easily censoring smaller amounts of a request than otherwise have to - possibly sometimes showing that part has been hidden). So the idea was to generalise the special setting for comments "visible", and make it on info_request_event.rb instead.

I think (but I'm not sure) that I thought this should be called prominence (same as in InfoRequests, but more granular), have options of normal/hidden/requester_only. And that variable is in the database, but largely unused (there is an InfoRequestEvent.user_can_view? which is a rough copy of InfoRequest.user_can_view?, but which isn't called)

[RichardTaylor]

It would often be helpful to hide individual incoming messages.

(Often admins actually only want to hide a particular attachment from a message).

Greater transparency over what we are hiding and why would be possible if we could take more finely grained action than hiding a whole request.

Hiding (rather than deleting) is useful while we are making a decision on what to do in response to a request to take material down. There are now a range of circumstances including defamation and accidental releases of information where we take information down first, and then discuss/decide what action ought be taken.

An option to add reasons for hiding material would be great too.

[RichardTaylor]

As WhatDoTheyKnow is changing its policies to move to quicker takedown of information in response to a wider range of takedown requests (while decisions are taken on a course of action) I think this is more urgent so we can be more transparent about what we're doing.

[crowbot]

Breaking this down into component parts, I think we need to:

• Refactor comment visibility to use the info_request_event
• Migrate the comment visibility data to info_request_event - this migration script needs to be made available to alaveteli users and referenced in the upgrade notes.
• Add an admin interface for changing the visibility of an info_request_event
• Add a field for prominence notes
• Add the front end view logic for displaying an info_request_event depending on its prominence - see app/views/request/_hidden_correspondance.html.erb (currently not used) as an example of how this might work

[crowbot]

I think there is also some interaction with our existing caching of attachments - we'd need to check that info_request.all_can_view? is replaced by something like info_request_event.user_can_view? so that cached attachments from hidden or requester_only incoming messages are not cached and served up directly from apache.

[crowbot]

As this is a proper new feature, going to push out release 0.13 first in the interests of keeping releases fairly small and managable.

[crowbot]

Looking at the details of this, I think it's going to be better to keep the prominence data attached to the comment, incoming_message and outgoing_message objects, not the info_request_events. There's a many-to-one relationship between the events and the comments and messages, so I think the logic will be more straightforward if the prominence is kept on the object itself.

[hsenag]

We would probably normally want to have something in place of the removed message, e.g. giving an explanation of why the message has been removed (see #423).

[crowbot]

Yep, at the moment I'm thinking of text something like 'This response has been hidden'. Then if a note has been added, "The reason for hiding it is: x" or otherwise "There are various reasons why we might have done this, sorry we can't be more specific here. Please [contact us] if you have any questions."

How does that seem?

[hsenag]

Sounds fine - was just checking because the existing hiding stuff doesn't allow for explanations.

Perhaps "This message has been hidden" since it might also be an outgoing message not an incoming one, though less commonly.

[crowbot]

OK, a new breakdown of tasks, based on #209 (comment):

• Remove vestigal prominence field and associated code from InfoRequestEvent model
• Add prominence field and prominence_reason field (for the explanatory note) to IncomingMessage
• Ditto OutgoingMessage
• Hide/display the message in the request thread and display the appropriate message for 'hidden' and 'requester_only' for any user, requester, and admin user respectively.
• Extend display code to cover OutgoingMessage too.
• Ensure that hidden and requester_only incoming messages are not indexed for search
• Ditto outgoing
• Admin interface for changing the prominence of an IncomingMessage - needs to expire caches, prompt a reindex, log an event "hide correspondence"
• Extend admin interface to cover OutgoingMessage
• Figure out what (if anything) to do about responses to hidden incoming messages. Can they be responded to? If so, do we need to not include quoted text when a requester is responding to to a hidden or requester_only incoming message?
• Hide attachments appropriately for hidden or requester only incoming messages. Also make sure they aren't cached.
• Add logic to cover hidden incoming and outgoing messages to the "Download entire request" option

[crowbot]

Figure out what (if anything) to do about responses to hidden incoming messages. Can they be responded to? If
so, do we need to not include quoted text when a requester is responding to to a hidden or requester_only
incoming message?

I think the cleanest, clearest thing to do here is to not allow a hidden or requester_only message to be responded to.

[crowbot]

I've made a pull request for this now #1058

[crowbot]

Merged.