With the addition of template folders we need to filter templates
based on a combination of type and parent folder ID.
This replaces the existing `templates_by_type` method with
`get_templates`, which supports both type and parent folder filters,
avoiding a need to create specific methods for each use case.
We still need the templates property to exist in some way in order
to cache it, but it needs to be clear that it's different from
`.get_templates`. One option was to make it "private" (i.e. `_templates`),
and always use `.get_templates` in the rest of the code, but this requires
adding "include all folders" to `.get_templates`, which doesn't have an
obvious interface since `parent_folder_id=None` already means "top-level
only".
This will probably come up again when we need to look into adding
templates from nested folders into the page for live search, but
for now renaming `Service.templates` to `.all_templates` makes it
clear what the property contains.
We do a lot of logic around choosing which templates to show. This logic
is all inside one view method.
It makes it cleaner to break this logic up into functions. But this
would mean passing around variables from one function to another.
Putting these methods onto a class (the service model) means that
there’s a place to store this data (rather than having to pass it around
a lot).
Making this code more manageable is important so that when we have
templates and folders it’s easy to encapsulate the logic around
combining the two.
We have teams who are using the dashboard every day, and being
confronted with this alarming yellow banner. There’s no action they need
to do since they’re only looking at the messages sent.
So this commit removes that banner from the dashboard. It also removes
the CSS and HTML for it from the app entirely because this is the last
remaining place we were using this style of banner.
we branch on any_ to either say "require ALL these permissions" or
"require ANY of these permissions". But we only ever call the decorator
with one permission, or with any_=True, so it's unnecessary
rather than allow admins to do everything specifically, we should
only block them from things we conciously don't want them to do.
This is "Don't let platform admins send letters from services they're
not in". Everything else the platform admins can do.
This is step one, adding a restrict_admin_usage flag, and setting that
for those restricted endpoints around creating api keys, uploading CSVs
and sending one-off messages.
Also, this commit separates the two use cases for permissions:
* user.has_permission for access control
* user.has_permission_for_service for user info - this is used for
showing checkboxes on the manage-users page for example
With this, we can remove the admin_override flag from the permission
decorator.
- Removed the code for the template_history endpoint and replaced with a
redirect to the new page so that anyone is forwarded on
- Updated the template to point to the new template_usage page
This commit adds two things:
a section on the dashboard to show how many inbound messages the
service has received in the last 7 days, and how recently an inbound
message has been received
---
Doesn’t show the contents of any messages, just like how the rest of the
dashboard is an aggregation, never individual messages.
a page to show all the inbound messages the service has received in
the last 7 days
---
This shows the first line of the message. Eventually this will link
through to a ‘conversation’ page, where a service can see all the
messages it’s received from a given phone number.
- ‘messages sent per month’ is a better description of what will appear
on the page than ‘activity breakdown’
- ‘templates used by month’ instead of ‘this year’ for consistency
I think ‘usage breakdown’ still works for the remaining link – it’s more
than a monthly breakdown, it also breaks down the spend.
Doesn’t need to say ‘by month’ in the `<h1>`s themselves, because you
can see from looking at the page that it’s broken down by month.
In pages specific to a service (e.g. dashboard and sub pages) the title
needs to distinguish which service it applies to. This is mainly to give
context to screen reader users who could be managing multiple services.
Implementing this uses template inheritance:
`page_title` includes `per_page_title` includes `service_page_title`
‘GOV.UK Notify’ is inserted into every page title.
Pages that set `service_page_title` get the service name inserted too.
The previous, weekly activity breakdown was what we reckoned might be
useful. But now that we have people using the platform it feels like
aggregating a service’s usage by month is:
- matches the timeframe users report on within their organisation
- is consistent with the usage page
And like the usage page this commit also limits the page to only show
one financial year’s worth of data at once (rather than data for all
time).
This commit also makes some changes to the jobs view code so that our
aggregation of failure states is consistent between the dashboard pages
and the jobs pages.
On the dashboard:
- adds a new ‘in the next 24 hours’ section to the dashboard which lists
upcoming jobs
- tweaks some spacing on the dashboard so that it doesn’t look like too
much of a mess
- don’t show scheduled jobs in the table of normal jobs
On the jobs page:
- don’t show scheduled jobs
The "you only have permission to view this service" banner sort of
makes sense if you don’t have _any_ permissions, but it doesn’t if you
have permission to create API keys. If you can create API keys you can
do a lot more than just view the service.
This banner was always being shown because the template was never
getting sent the service’s templates from the API.
This commit fixes this to only show the banner when a service has no
templates, and adds some tests to make sure it doesn’t happen again.
Since we’re removing the write email/write text message calls to action
from the tour, we should reintroduce them to the dashboard, for users
who are unsure what they should do next.
This commit extends the `ajax_block` component to take a `dict` of
partials, from which it can select the partial matching its `key`
argument and print its HTML to the page.
This means that the same markup is only rendered in one place, rather
than in two (individually in the JSON endpoint and as `include`s in the
parent template).
This is less repetitive than typing out the HTML with all its attributes
every time.
It also lets us wrap up the idea of ‘finished’ as a parameter, so the
AJAX code will only be initiated when it’s needed, eg if a job is still
processing.
Previously, the AJAX update for the dashboard was returning a big blob
of JSON with one key.
This commit splits it up to return:
- one key for each section of the page
- each containing a smaller chunk of HTML rendered from a partial
The jobs page was already working this way (pretty much) but just needed
a little tweaking to get it the same.
Previously the structure was
```
dashboard.html
|_ today.html
|_ some random html
|_ a few things split into partials
```
This commit simplifies the structure to just be:
```
dashboard.html
|_ partial
|_ partial
|_ …
```
The dashboard looked a bit table-y. This commit makes four main changes:
- show a bar chart (drawn in CSS) for template usage (only shown if
you’ve used more than one template recently)
- only break down template usage by template name, not template type
(because that’s happening with the big numbers)
- change the style of the ‘show more’ links under each section so that
they are all consistent, and a little less busy (one less keyline)
- remove the ‘recent templates‘ title so that the first two sections of
the page group under ‘in the last 7 days’
Takes the number of emails and SMS fragments sent from:
https://github.com/alphagov/notifications-api/pull/273
Using these numbers it’s possible to show:
- how much of your allowance is left
- or how much you have spent
For now the allowance and rates are hard coded.
Only for users that have manage service.
Currently, when we update a section of the page with AJAX we replace the
entire HTML of the section with the new HTML. This causes problems:
- if you’re trying to interact with that section of the page, eg by
inpecting it, clicking or hovering an element
- (probably) for screenreaders trying to navigate a page which is
changing more than is necessary
This commit replaces the call to `.html()` with a pretty clever library
called diffDOM[1]. DiffDOM works by taking a diff of the old element and
the new element, then doing a patch update, ie only modifying the parts
that have changed.
This is similar in concept to React’s virtual DOM, while still allowing
us to render all markup from one set of templates on the server-side.
1. https://github.com/fiduswriter/diffDOM
(except view activity, natch)
> No permissions – Remove trial mode banner
> No permissions – Add blue banner saying 'You only have permission to
view this service'
This commit adds a 3 screen tour, similar to those used on GOV.UK Verify
and Passports.
We guerilla tested this on Friday, and it really helped users to build a
mental model of how Notify works, so that when they’re playing around
with it they have a greater sense of what they’re aiming to do. This
makes concepts like templates and placeholders click more quickly.
https://www.pivotaltracker.com/story/show/116710119
Previously the ‘get started’ block on the dashboard pushed users into
starting with a text message. This led to users writing email content
into a tet message template because it didn’t match their expectations.
Also, the ‘send yourself a test’ link from the dashboard:
- wasn’t much used, because users responded to the similar call to
action on the choose template page instead
- was confusing if you had created an email template because it
presupposed that you’d created a text message template
So this commit changes the ‘get started’ block to be a choice between
creating an email template or a text message template. We reckon that
the language of ‘set up’ will help establish that templates are not
equivalent to individual messages. This language is now repeated on the
‘choose template’ page when you don’t have templates as well.
Some pages with AJAX should update quickly, because the data is likely
to be changing quickly, and be finished changing sooner. Other pages we
want to have tick over a bit slower.
This commit adds an optional ‘interval’ parameter to the updateContent
modules, which sets how often the page should ping the server for an
update.
It then sets the interval for the dashboard page to be 10 seconds,
rather than the default 1.5 seconds.
This commit adds two new sections to the dashboard
1. A banner telling you about trial mode, including a count of how many messages
you have left today, which is a restriction of trial mode
2. Panels with counts of how many emails and text messages have been sent in a
day, plus the failure rates for each
It does **not**:
- link through to any further information about what trial mode is (coming
later)
- link through to pages for the failure rates (coming later)
- change the ‘recent jobs’ section to ‘recent notifications’
