This adds an option on the organisation settings page to add
'request_to_go_live_notes'. When a service belonging to this
organisation requests to go live, any go live notes for the
organisation will be added to the Zendesk ticket in the 'Agreement
signed' section.
Our usability testing found that jumping out of the service when going
to download the agreement made it difficult for people to find their way
back to the ‘Request to go live’ page.
This commit adds a duplicate, service-specific versions of these pages
which have the same content but:
- keep the service navigation
- have a link back to the ‘Request to go live’ page
remove `confirm` from `confirm_remove_user_from_service` as there's
only one action now that the initial confirmation prompt takes place
on the edit permissions page
when you hit the delete button, it flashes the delete button and takes
you to the `/service/../user/../delete` url. If you then click the save
button, it would make a POST to the delete URL... and delete the user.
now the page stays on the edit url, but adds a `?delete=yes` query
string. The dangerous flash banner now has an action field which
defines where the browser will make the POST to (which remains at
/delete).
Adds a front end for:
https://github.com/alphagov/notifications-api/pull/2417
> Sometimes we have to make a few services for what really is one
> service, for example GOV.UK Pay and GOV.UK Pay Direct Debit. We also
> have our own test services which aren’t included in the count of live
> services. We currently count these as one service by not including
> them in the beta partners spreadsheet.
In the short term I have created a duplicate version of the letter-validation-preview so that people from a service can upload a pdf and see why the letter isnot validating.
It's hard to get a precompiled letter to validate when starting to integrate with Notify. This will return the overlay of the letter validation and is now available to the services.
At the moment they send us a PDF to upload.
This is temporary because there is a story to create a one-off flow to get this overlay, that will replace this page.
There is no navigation to this on purpose.
We get a bunch of requests to go live where people have told us they're
going to send email but there is no email reply-to address present.
These come from 2 scenarios:
1. when there are email templates, and no reply to address – but they
ignore the checklist
2. when there are no email templates (yet) but they provide anticipated
volumes for email
At the moment we only auto-check for a reply to address when they have
email templates. And because the question about anticipated volumes
follows the checklist, you'll get a checklist that passes (reply
addresses not required as no templates present) - but your future intent
that differs (reply address IS required because you have anticipated
volumes).
So let’s bring the request for anticipated volumes into the checklist,
that way we can dynamically add the requirement for a reply to address
if they say they will send email but don't have templates yet.
We should begin storing it in the database against the service to stop
people having to re-enter it each time they try to complete the go live
screens.
This also means moving the ‘consent to research question’ along with
the questions about volume, because
- we want people to answer both before going live
- we don’t want to clutter up the summary page by asking questions there
too
Most of the existing platform admin buttons on the service settings
page used to issue GET requests to switch service settings. This
means they weren't protected by CSRF. On top of that as our number
of service permissions increases over time a lot of buttons on the
page made it hard to work with.
To fix these issues we replace most of the buttons with rows in the
platform admin settings table. Each setting has a 'Change' link that
leads to a page with an On/Off switch form.
This removes "research mode" switch completely since we're planning
to deprecate it in the future and we don't expect to switch any new
services into research mode at the moment.
Most service permissions are now handled by a shared endpoint that
is parameterized with the permission name. Some permissions that
require some additional logic before they can be toggled (like document
upload, which requires setting a contact address) have separate
initial endpoints that redirect to `set_service_permission`.
"Archive", "Suspend" and "Resume" actions are kept as buttons since
they display a confirmation banner (which is a CSRF-protected form)
and they're not easily represented as an On/Off switch.
This adds a preview pane which is visible when updating a letter brand.
If JavaScript is enabled, the preview pane shows on the set-letter-branding
page, and submitting the form saves updates the letter brand for a service
immediately. If Javascript is not enabled, there is a separate 'Preview email
branding' page which shows a preview of the brand and has a 'Save' button on it.
a form that allows you to clear entries from the cache for all of
either users, services or templates. It'll tell you the largest amount
of keys deleted, since there are multiple keys associated with each
model.
This works in a similar way to the create_letter_branding view function,
but with a few minor differences:
* Since we already have a file, uploading a file is no longer required
(since we can just use the current file if a new one is not uploaded)
* We save the changes in the database, then upload the new files to S3.
If saving to S3 raises an error, we now rollback the database changes to
prevent any errors when trying to view letters with the original logo.
This is a platform admin page which lists all letter brands and their
domain. Once the page to edit a letter brand has been created, each
brand will link to its edit page, but for now this is just a list of
brand names and domains.
This has a form with 3 fields - the file upload field, logo name, and an
optional logo domain. Logos need to be uploaded in `.svg` format and we
then convert this to `.png` format and upload both file types to S3 as
well as saving the letter branding details in the database.
Added a link to cancel letters from the letter notification pages if the
letter is still able to be cancelled. Clicking on this link will show a
confirmation box, and will then cancel the letter if the user confirms.
When we first built letters you could only send them via a CSV upload, initially we needed a way to send those files to dvla per job.
We since stopped using this page. So let's delete it!
- Add a GET / POST view: manage template folder
- Add a template for that view, where a user can rename their
folder
- Add an API client method for updating a folder
- Test the new feature, including the test that service without
permissions cannot manage a folder
The add new templates page now has option to add template folders.
Tweaked wording of other options and h1 to clarify options since it's
not all about templates any more.
Added api client and stuff for it
We didn’t used to allow this because it wasn’t really possible with the
old DVLA set up and we didn’t think there’s a need.
We think it’s possible now because, even though it’s cumbersome, it’s
better than the manual process.
- add get/post view
- create a pdf upload form
- add a template where user can upload the file
- check boundaries of the letter by calling template-preview
- display banner messages with boundaries validation result
- display pages of the document, with visible boundaries overlay
if the document did not pass validation, and without overlay
if they do pass validation
Added a new row to the settings table, 'Post class', which shows the
default letter class of a service and is only visible to Platform Admin.
Also added a new page to enable Platform Admin users to change the
default letter class for a service - this only has two options at the
moment, 1st class only and 2nd class only.
A platform admin form accepts a list of references (one per line)
received from DVLA and sends them to the API to update notification
statuses.
References we get from DVLA start with `NOTIFY00\d`, which isn't
part of the reference we store in the database, so we remove them
before sending the data to the API.
The new `returned-letter` status should be treated as `delivered`
for now until we decide a way to display returned letters to users.
