Skip to content

maintainers.md

Latest commit

 

History

History
133 lines (92 loc) · 4.54 KB

maintainers.md

File metadata and controls

133 lines (92 loc) · 4.54 KB

Maintaining contact-frontend and deskpro-ticket-queue

Prerequisites

The easiest way to run Mongo is using docker.

You will need the DESKPRO_TICKET_QUEUE service running locally:

sm2 --start DESKPRO_TICKET_QUEUE

To run locally

To start the application locally with the test-only endpoints enabled,

./run.sh

You should then be able to navigate to the following endpoints:

Running all unit and integration tests together

To run the Scala unit and integration tests,

sbt test it/test

Running UI acceptance tests and accessibility tests

To execute the UI acceptance tests on your local machine, follow the guidance in the contact-frontend-ui-tests repository. These will also run the accessibility tests via ui-test-runner.

ADRs in contact-frontend

We are using MADRs to record architecturally significant decisions in this service. To find out more visit MADR

See our architectural decision log (ADL) for a list of past decisions.

How to create a new ADR

  1. Install Node if you do not have this already. Node includes npm.

  2. Install adr-log if you do not have this already

    npm install -g adr-log

  3. Copy template.md as NNNN-title-of-decision.md, and fill in the fields. Do not feel you have to fill in all the fields, only fill in fields that are strictly necessary. Some decisions will merit more detail than others.

  4. To re-generate the table of contents, run

    ./generate-adl.sh

Email validation in contact-frontend

Background

Validation of email addresses on the server side within contact-frontend has some complexity to consider. Specifically, there is a known unhappy path that can occur:

  1. End user submits a form via contact-frontend, with an email addresses that passes validation within contact-frontend on the server side controller

  2. Ticket is created in the encrypted Mongo-backed queue within deskpro-ticket-queue

  3. Ticket is sent asynchronously to Deskpro, which may use different email validation rules. If the ticket has been created with an email addresses that does not pass Deskpro's validation rules, it will be repeatedly submitted to Deskpro as a scheduled POST until it reaches a maximum number of retries, at which point it is marked as permanently failed and deleted after the TTL expires (at time of writing, 200 days).

The decision has therefore been taken to align contact-frontend with the email validation rules in Deskpro. These are written in PHP Perl Compatible Regular Expressions (PCRE) syntax.

Translating PCRE regexes to Scala

Most of the regex syntax used by PCRE is standard and does not need any modification to be usable in Scala. However, there are a few things of which to be aware.

  1. In the Deskpro PCRE regexes in their provided source code, the # symbol is used as a delimiter at the start and end of the regex. When converting to Scala, these can be deleted.
'#^[a-Z0-9]{1}#'

becomes

"""^[a-Z0-9]{1}""".r
  1. The PCRE regexes use a final i to denote that a regex is case-insensitive. In Scala, this should be leading (?i)
'#^[hello world]{1}#i'

becomes

"""(?i)^[hello world]{1}""".r
  1. PCRE regexes may escape the # and other special character that may be used as delimiters. These do not need to be escaped in Scala.
'#^[a-z0-9!\\#$%&\'*+/=?^_`{|}~-]+#i'

becomes

"""(?i)[a-z0-9!#$%&'*+/=?^_`{|}~-]+""".r

Useful resources

PCRE Manual

regular expressions 101 PCRE regex checker