Add grace period for making published requests private

[garethrees]

Context

Currently we're inconsistent – both in policy and in-app capability – on how and when Pro users can apply privacy periods to public requests.

At present, individual requests can be made private at any time (https://github.com/mysociety/alaveteli-professional/issues/578), while batch requests cannot be made private after publication (#5353).

Our current internal policy is that we allow a grace period where published batch requests may be manually re-embargoed by tech support in the case of mistakes, but that's not clear from the in-app help text or capability.

We'll fix this by making the privacy period options consistent across single requests and batches, and technically enforce a grace period of 24 hours after publication within which privacy periods can be added.

Fixes https://github.com/mysociety/alaveteli-professional/issues/578
Fixes #5353
Fixes mysociety/whatdotheyknow-theme#976
Fixes #6321

Mechanics

There are four possible states that we need to handle:

1. Request is private; privacy period can be extended
2. Request is private; privacy period cannot be extended
3. Request is public; privacy period can be added
4. Request is public; privacy period cannot be added

For private requests, whether the privacy period can or cannot be extended is determined by the embargo expiry date. Nothing is going to change here.

For public requests, we'll add a grace period that allows an embargo to be added for up to 24 hours after publication. This will apply to both new requests created without a privacy period, and requests that were private and have subsequently been published.

Here's a sketch of what should appear for a request in each state. A request in a batch should have identical options, but – as they do now – make clear that the privacy period / publication applies to all requests within the batch.

Text Updates

We'll want to convey the behaviour of the grace period around the site.

1. In the "Private requests" section on /help/pro
2. On the new request page where pro users can add a privacy period to a new request
3. Within email alerts that tell pros that the privacy period is ending. It should be clear that they'll have a limited opportunity to act.
4. Perhaps on the dashboard where we say that privacy periods are expiring.
5. Given this is a significant policy and behaviour change, we'll want a blog post & on-site announcement that links back to the blog post.

Interaction with email alerts

Given we're only allowing a short grace period of 24 hours, we'll need to ensure that pro users have enough time to act on the notification.

We should ensure that embargo expiring notifications are always sent with several working days for the user to act on them before publication.

We don't want to be in a situation where the majority or all of the grace period has elapsed before the user even receives a notification. We do send notifications that the privacy period will be expiring well in advance which should give enough warning, but we want to be sure that the privacy period expired notifications also make sense with this change.

It's been noted a few times that users have "missed" the notifications (#6761). Re-engineering them is out of scope here, but we should keep an eye out for any quick and cheap improvements that we can make.

Other considerations

I'm not sure how we phrase the policy. "Requests can only be made private up to 24 hours after being published" feels a little confusing, so we'll want to get this as crisp as we can.

We currently say "Change privacy or publish now" when a request is already published. If possible, it would be good to drop "or publish now" for public requests. Not essential – only if it ends up being easy and doesn't add too much complexity.

We'll want to re-emphasise the grace period in the confirmation dialogue and in the flash message rendered when a request is published, so that it's clear to users that they have a limited amount of time to change their mind.

We'll add a new "Read more or contact us" element to the sidebar privacy section. "Read more" should link to /help/pro, where we'll need an update to explain this grace period. "contact us" can obviously link to the contact form.

Bonus – Fix the privacy change input

It's really surprising that selecting a value in the privacy select input actually changes the privacy of requests.

After the main work of adding a grace period has shipped, if there's time it would be nice to fix this by adding a button to save the update so that both "change privacy" and "publish now" are active decisions.

Out of Scope

While discussing this in general we had an idea (https://github.com/mysociety/alaveteli-professional/issues/578#issuecomment-1128656678) to use backpage as a transition stage for requests within the grace period.

We won't tackle that here as there'll be a lot to unpick in terms of how the prominence states would get applied, and how Tracks would respond to these state transitions.

[WilliamWDTK]

We've had a WDTK Pro user get in touch with us about this recently:

Or in other situations, batches of requests have been published where I've missed an alert to say that they will be placed in the public domain. Nine times out of ten I'm happy for the requests to be published, but again, there have been one or two which I'm still working on and don't have the option to put them back under embargo […]. It can be quite frustrating sometimes.

[garethrees]

This is desirable, but unlikely to be worked on in the next 12 months so closing for now.