A new permission has been added, view_activity, to resolve this issue.
Another pull request in notifications-admin will be required to update all users with a default permission of view_activity.
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.
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.
Use one page template for each of:
- choosing a message template
- adding recipients
- checking an email message
- looking at a job
This commit consolidates the two templates into one, and adds logic to show
the SMS message pattern or the email message pattern depending on the type of
template.
It also gives email templates a bit more width, because the body and the from
address tend to be quite long.
This commit brings in the `Template` util, added here:
https://github.com/alphagov/notifications-utils/pull/1
It also does a fair bit of tidying up, which I’ve unfortunately squashed into
this one massive commit. The main change is moving 404 handling into the
templates dao, so that every view isn’t littered with `try: … except(HTTPError)`.
It also adds new features, in a prototypy sort of way, which are:
- download a prefilled example CSV
- show all the columns for your template on the 'check' page
This commit:
- adds the template to the jobs page (and puts it at the top of the send SMS
page) so that it consistently appears in the same place throughout the
journey
- put the real data about a job on the jobs page and on the dashboard
From the:
- dashboard
- activity page
This info will be confusing for users at the hack day, because it will say
they’ve already sent messages when they first sign up.
This involved changing the table macro to have a nice ‘no rows’ message.
Having the full history of the message is more information than is necessary.
We should only show what stage the message is at, and the time that it reached
that stage.
We can do research later on to find out if users understand or care about the
different stages.
- adds a table of recent activity to the job page, which is shared by the
dashboard page
- uses the same filename and message template as the first job shown on the
dashboard
- sets the time of file uploads/message delivery/message sending to always
match ‘just now’
These are basic tests to make sure that the pages stay stitched together.
Added for both the jobs and send SMS flows (because the send SMS flow didn’t
have any before)
This mocks out a data structure for a job’s messages, and renders this data:
- on the notification page, as a table, which links through to…
- …the page for an indidivual message
