This changeset pulls in all of the notification_utils code directly into the admin and removes it as an external dependency. We are doing this to cut down on operational maintenance of the project and will begin removing parts of it no longer needed for the admin.
Signed-off-by: Carlo Costino <carlo.costino@gsa.gov>
The links in the blue boxes on the job page needed hidden text so that
they work out of context. This changes the text from "10 sending" to "10
sending text messages" (with the message type hidden text).
We have lots of functions for converting various types of data into
strings to be displayed to the user somewhere.
This commit collects all these functions into their own module, rather
than having them cluttering up `app/__init__.py` or buried amongst
various other things that have ended up in `app/utils.py`.
Changes those fields in the following forms:
- SearchByNameForm
- SearchUsersByEmailForm
- SearchUsersForm
- SearchNotificationsForm
Includes changes to templates that use this form
and associated tests.
`EmailPreviewTemplate.subject` returns a string of HTML, with any
user-submitted HTML already escaped:
b5a61bfb7b/notifications_utils/template.py (L672)
What won’t be escaped is the HTML needed to redact the placeholders. We
generate this HTML so we know its safe, and doesn’t need to be escaped.
However when we pass it to Jinja, Jinja doesn’t know this, so will try
to escape it. This means users will see the raw HTML.
We can get around this by using Flask’s `Markup` class to tell Jinja
that the string is already sanitised and doesn’t need escaping again.
Text message templates don’t have this problem because they already
return `Markup`: b5a61bfb7b/notifications_utils/template.py (L288)
Letter templates don’t suffer from this problem (because they don’t
support redaction) but without making the same change they would still
double-escape ampersands, greater-than symbols, and so on.
We’re now normalising and storing the whole address in the
`normalised_to` field. Previously we were only storing the first line
of the address.
Enough time should now have passed that the field will have been
populated for all letters in the database.
Thus we can now tell users that it’s not just the first line they can
search by.
If you’ve come to look at a notification via the uploaded letters page
then the ‘< back’ link should take you back there, not to the usual
activity page.
Some teams have started uploading quite a lot of letters (in the
hundreds per week). They’re also uploading CSVs of emails. This means
the uploads page ends up quite jumbled.
This is because:
- there’s just a lot of items to scan through
- conceptually it’s a bit odd to have batches of things displayed
alongside individual things on the same page
So instead we’re going to start grouping together uploaded letters. This
will be by the date on which we ‘start’ printing them, or in other
words the time at which they can no longer be cancelled.
This feels like a natural grouping, and it matches what we know about
people’s mental models of ‘batches’ and ‘runs’ when talking about
printing.
This grouping will be done in the API, so all this commit need to do is:
- be ready to display this new type of pseudo-job
- link to the page that displays all the uploaded letters for a given
print day
The search form makes a post request, so that phone numbers and email
addresses don’t show up in logs or browser history.
At most the API will return 50 results, with some pagination links. We
can’t easily give you links to click in the admin app, because links can
only perform get requests.
Because the value of seeing more than 50 results feels quite low (users
will probably make their search more specific before scrolling through
all 50) let’s just show a message saying only the first 50 results are
displayed.
Like we have search by email address or phone number, finding an
individual letter is a common task. At the moment users are having to
click through pages and pages of letters to find the one they’re looking
for.
Users of the API will also be able to search by reference, same as for
emails and text messages. But we only show this hint text to users who
have some API keys.
The uploads and jobs page should start showing in the _Uploads_ menu on
the left hand side.
If you’ve navigated to a job from the uploads page (ie you haven’t got
to that page because you’ve just sent the job) then you should see a
link back to the uploads page.
The logic around what gets shown on the uploads page was hard to follow.
This commit makes three changes to hopefully make it easier:
- remove the passing-around of a string containing the contents of a
rendered partial
- encapsulate everything in one `show_scheduled_jobs` variable, rather
than mixing between `scheduled_jobs` and
`current_service.scheduled_jobs`
- adds a comment to explain why we still render `_jobs.html` even when
we know we have no jobs
