The content length message was making the page jumpy and causing reflows
in three ways. This commit addresses each of those ways:
As the user scrolled
---
The footer went from fixed to sticky and the spacing around the message
changed. This change in spacing was needed so that the message looked
right in both contexts.
I think the best way to resolve this is to not use the sticky footer
when editing text message or broadcast templates.
On my 1440×900 screen I can fit a 5 fragment text message, plus the
‘will be charged as 5 text messages’ message, plus the save button.
Our top 10 screen resolutions according to our analytics are:
Position | Resolution | Percentage of users
---------|------------|--------------------
1 | 1920x1080 | 27.37%
2 | 1280×720 | 11.07%
3 | 1366×768 | 8.88%
4 | 1536×864 | 5.79%
5 | 1440×900 | 4.52%
6 | 1600×900 | 3.71%
7 | 1280×1024 | 3.10%
8 | 1680×1050 | 2.42%
9 | 1920×1200 | 2.33%
10 | 2560×1440 | 1.99%
When the page first loaded
---
The message is empty so takes up no space, then the javascript fires
and inserts the message, taking up a line of space.
This is resolved by making the empty message take up space with a
non-breaking space character.
When the user first typed
---
We previously didn’t show any message until the user started typing.
This meant that, with the above fix, there was a larger than normal
empty space between the textarea and the save button.
This is resolved by always showing the message, even when the user
hasn’t typed anything yet.
***
These are design decisions which made sense when the message was
displayed along side the button, but we’ve had to change now that the
message is above the button.
Users sending text messages are sometimes unaware that long messages
will cost more.
Users sending broadcast messages need to be aware that there’s a
character limit, so they can take this into account when planning their
messages.
This commit adds an endpoint which counts the number of characters in
some template content, and returns a snippet of useful info about how
long the message is.
In subsequent commits we’ll be able to use AJAX to fetch this snippet as
the user types.
There’s a surprising amount of complexity in counting the length of
messages. So we’ll need to do this in Python because it would be too
convoluted to re-implement the length counting in client side code, let
alone ensuring it had parity with its Python equivalent.
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`.
`app/utils.py` is a bit of a dumping ground for things we don’t have a
better place for.
We now have a place and structure for storing ‘model’ code (‘model’ in
the model, view, controller (MVC) sense of the word).
This commit moves the spreadsheet model to that place.
We shouldn’t have a page where someone can look up any other user’s
email address based on their user ID.
We also don’t want a page where a malicious user could send someone an
link which would get them invited to the service.
Restricting the invite to be populated just from users in their own
organisation doesn’t mitigate against this stuff completely, but they
probably have a way of finding out the email address of someone in their
organisation already.
At the moment users must be invited to join a service. But this means:
- users must know that a service already exists
- they need to know who to ask for an invite
If the user doesn’t know these thing then sometimes they just go ahead
and set up a new service. Which means they have to get all the way to
the point of requesting to go live before we tell them that there’s
already a service with a similar name or purpose.
So we should let users:
1. discover what other services exist in their organisation
2. apply to join a service
3. automatically notify the service managers of their interest
4. be invited by a service manager
5. accept the invite
This commit implements step 4. We can just link them to the invite form
in step 3., but we should make it easy for them to send the invite,
without having to copy and paste email addresses.
So this commit let the invite form be pre-populated with an existing
user’s email address.
Depends on:
- [ ] https://github.com/alphagov/notifications-utils/pull/826/files
Adds error messages for when the content of a broadcast template is too
long.
The error message is explicit when this is cause by non-GSM characters.
We may not want to expose this complexity to our users, but it’s useful
for now while we’re testing things out.
It’s one of the things we check when someone makes a request to go live,
and putting it in the ticket means we don’t have to take the extra step
of clicking into the settings.
Also added some line breaks to chunk things up a bit more clearly.
Effects all routes that use that form, or
SetLetterBranding, which inherits from it:
- /organisations/<service_id>/settings/set-letter-branding
- /organisations/<service_id>/settings/set-email-branding
- /<service_id>/service-settings/set-letter-branding
- /<service_id>/service-settings/set-email-branding
There was a recent error in the logs because a service tried to change
its name to one exceeding 255 characters (which is a limit on the
database field). We can easily catch these errors on the form, so that
the user doesn't see an error page.
When we get a support ticket we need to check whether a user has any
live services.
We have a method for this on the user model now, so we don’t need a
separate function in the feedback code.
It wasn’t very well tested so I’ve adapted the old tests from the
feedback view to work against the method on the user model too.
Changes OrganisationCrownStatusForm.crown_status.
This also effects NewOrganisationForm, which
inherits from OrganisationCrownStatusForm.
Because of that this commit also updates the
template used for the edit org crown status page,
which uses NewOrganisationForm for its form.
Changes the OrganisationTypeField class used by
OrganisationOrganisationTypeForm.organisation_type
OrganisationTypeField is also used by the forms in
/add-service:
- CreateServiceForm
- CreateNhsServiceForm
Because of that, this commit also includes changes
to the template for that route.
Note: this also moves where OrganisationTypeField
appears in app/main/forms.py so it can use
GovukRadiosField.
Includes changing form.enabled to use
OnOffField, for consistency with other on/off
fields.
OnOffField's data is a boolean, not a string, so
some of the logic using it needed to be changed.
On the uploads page we only show jobs which are within a service’s data
retention.
This commit does the same for when we’re listing the jobs for a contact
list. This matches the UI, which says a contact list has been ‘used
`<count_of_jobs>` in the last <data_retention> days’
It’s a bit unintuitive that starting a job from a contact list makes a
copy of the file, which has no relationship to the list it was copied
from. This is more of an implementation detail, rather than something
that comes from people’s mental models of what is going on. Or at least
that’s what I hypothesise.
I think it’s clearer to show jobs that come from contact lists within
the lists that they were created from. By naming the jobs by template
this gives a clearer view of what messages have been sent to the group
over time.
The checkboxes component that lets you choose
which users have permission to see the folder is
currently using the noun of 'folder' in the
summary it generates.
This is because this page users the
TemplateFolderForm class, which defaults the
permissions to 'folder'.
This updates the field_label attribute, used by
the code that generates the summary, to 'user' to
match the type of permission.
Proof of concept for the GovukRadiosField class.
Includes the removal of the a DataRequired
validator. This doesn't seem to be needed as the
RadioField superclass catches any submissions
without any data from field.choices in its
pre_validate method (which also outputs the
correct error message).