How can we add special requirements?

[threedaymonk]

I'm using this issue to collect information, analysis, and recommendations.

This work is motivated by a specific need:

PSI 2.13 Visitors must be asked to specify special requirements or to request reasonable adjustment that they require to help them access the visit. See paragraph 3.8 for further details. If a reasonable adjustment needs to be made this information must be relayed to visits staff at the earliest opportunity.

At the point of booking visitors must be encouraged to declare any particular requirements due to a disability or an underlying medical condition that would normally require a reasonable adjustment to be made.

The problem

For various reasons (historical and related to information assurance sign-off), this application does not store prisoner or visit information in the database. Instead, this is serialised, encrypted, and passed around in URLs (to understand some of the drawbacks to this, see, for example, #336).

The de facto maximum length of a URL is 2000 bytes. This limits the amount of information about a visit that we can pass around in this manner, especially as every URL must start with https://www.prisonvisits.service.gov.uk.

The longest prefix for a URL is of the form /status/2e3f6d7b1b467cf7ba49072b89d04922?state=, meaning that even before we serialise our data, we have lost 86 bytes. Our serialised data must also be URL-escaped; this loses another two bytes in representing the single = as %3D. We could make some of this back with shorter paths, but not by much.

Thus, the output of the serialisation needs to be less than 1914 bytes; given the uncertainty introduced by the variable entropy of the information being compressed, a prudent limit is significantly lower. I suggest 1500 bytes as a round number.

Recommendations

In the long term, we should move this app to a more conventional database-backed structure. This would

• fix problems with overlarge sessions;
• allow us to add any additional fields in the future;
• remove the confusing double use of the visit_metrics_entries for metrics and for tracking booking status;
• eliminate a whole load of unnecessary complexity and idiosyncracy; and
• reduce the amount of state held outside the app in people's inboxes and thus make future changes easier.

However, this requires a change to the PIA. We should start seeking this now, because we will need it.

Short-term fixes

I have investigated whether a short-term fix – of adding a field to the form and adding its content to the serialised URL – is feasible.

• Names already have a limit of 30 characters via the NameValidator.
• With a maximal visit (maximum number of visitors, 30-character names of random letters), the serialised data consistently comes to around 1392 bytes, only slightly below the 1500-byte limit suggested above.
• Only about 50 bytes of additional data can be added without hitting the 1500-byte limit.

With real-world data, the entropy is lower, and we can probably accommodate more. However, we cannot confidently set a limit. My conclusion is that there is not enough space available in which to store additional free text reliably.

[mloughran]

The result: https://github.com/ministryofjustice/prison-visits-2