> If you have the Edit templates permission but not the Send messages permission, the navigation should read
>
> - Text message templates
> - Email templates
> - Letter templates
>
> The page headings should also read
>
> - Text message templates
> - Email templates
> - Letter templates
respectively
https://www.pivotaltracker.com/story/show/115488955
On the send messages and manage team pages we have big green buttons for
adding/inviting a new template or team member.
On the add template page it was at the bottom, and often got missed.
On the manage team page it was at the top, but maybe too prominent because it’s
big and green.
This commit tries putting it in the top right of the page instead (except when
the template page is empty, in which case it’s unchanged).
The same `.html` file is shared between adding a template and editing a
template.
The page heading needs to be contextual to the URL, either ‘add’ or ‘edit’.
Somewhere along the way this got lost; this commit reinstates it.
In research we’ve seen users struggle with this. Often they’d type
((Joe Bloggs)) or ((XX/XX/XXXX)) instead of a sensible name.
Lets see if explaining it differently helps.
Error messages were added to the yes/no fields on the invite user page in:
4c323a9a99
This commit fixes the margins and padding on these fields so they look
consistent with how we do validation errors elsewhere.
t
Previously the send button on the ‘Check and confirm’ page always said
‘Send x messages’, irrespective of whether you were sending emails or text
messages.
This commit makes it say one of
- Send 1 email
- Send 29 emails
- Send 1 text message
- Send 999 text messages
The template for viewing a job was not getting all the variables it needed in
order to display an email template. Hadn’t noticed this before, because email
templates require more variables than SMS templates.
This commit fixes that bug.
Makes uses of the additions to utils in https://github.com/alphagov/notifications-utils/pull/9
This commit strips out a lot of the complex stuff that the views and templates
in this app were doing. There is now a cleaner separation of concerns:
- utils returns the number and type of errors in the csv
- `get_errors_for_csv` helper in this app maps the number and type of errors
onto human-friendly error messages
- the view and template just doing the glueing-together of all the pieces
This is (hopefully) easier to understand, definitely makes the component
parts easier to test in isolation, and makes it easier to give more specific
error messages.
If a invited user accepts a cancelled invitation they are directed to a page telling them the invitation is cancelled.
Without this they were able to register and were added to the service.
This is a first go at having the job page update without refreshing.
The approach I’ve taken is to do all the rendering of HTML on the server side,
rather than use a Javascipt templating engine like mustache. This ensures that
we don’t have to maintain two sets of templates.
So the approach is to split the job page into partials. These partials can then:
- be included in the job page to render the whole page
- be rendered indivudually and then returned as a blob of HTML inside a JSON
response
Then I’ve added a Javascript module which looks for areas of the page that should
be reloaded. For each area of the page it will poll a URL and re-render that
section of the page when it gets new HTML. It implements some throttling so that
API calls will never happen more frequently than 0.67 times/second.
The template was displaying raw, eg ‘Hello ((name))’
This commit changes it to use the `.formatted_as_markup` property so the
template is rendered with:
- the placeholders as blue lozenges
- the service name prefixing the message
register. On succesful register and verfication they
will be added to service and forwarded to dashboard.
Nothing is done yet with the permissions requested in the
invite to the user.
CSV files currently have ‘to’ as the recipient column. This is changing in
https://github.com/alphagov/notifications-api/pull/109
The admin app also has to validate that the CSV files have the right columns,
because the API expects any CSV that it’s given to have been checked (also we
want things to actually work).
This commit is the minimum code change needed. In the future it should reuse
the same code as the API for processing CSV files. This will need more thinking.
