At the moment there’s nothing in Notify that says the logo on letter
templates can be changed from ‘HM Government’. While some people guess
that it’s possible, or are motivated enough to enquire, others might be
assuming that the branding can’t be changed (and thus deciding Notify
letters aren’t for them).
In the future we should make this process slicker (eg with a file
upload) but the easiest, quickest improvement to make for now is:
- let people know that the branding can be changed
- direct them to support if they do want to change it
Allows getting notification counts for a given number of days to
support services with custom data retention periods (admin
dashboard page should still display counts for the last 7 days,
while the notifications page displays all stored notifications).
Our research and prototyping around ‘basic view’ found that:
- a lot of users who send messages rarely or never look at the dashboard
(yet it’s the first page they see when they sign in)
- team managers like the idea of taking away things that users don’t
need in order to make the interface simpler
We’ve disentangled the simpler way of sending messages from being part
of ‘basic view’. This means we can give managers the option of taking
away the dashboard as an independent choice, not something that’s
wrapped up in a separate ‘view’.
I think that this checkbox is a more straightforward proposition than
‘basic view’ ever was (despite all the work we did to explain it and
develop the nested checkbox pattern). In research users would often
explain the feature back to us as being about hiding the dashboard – we
should try to make Notify operate in terms of concepts that come
naturally to people wherever possible.
‘Upload recipients’ and ‘Send to one recipient’ have always been
slightly clunky phrases.
Now that basic view jumps straight into the ‘Send to one recipient’
flow there’s no way for users to get to the ‘Upload recipients’ flow.
By adding a link to it from the ‘Send to one recipient’ flow it’s
possible for users of basic view to access it.
But we don’t want to introduce too much inconsistency between basic view
and admin view because users will be migrating from one to another. They
might also be talking to their manager, who wouldn’t be able to tell
them where to click if they were looking at two completely different
interfaces.
This also means that we can keep the left-hand navigation in basic view
nice and simple with the two options (‘Templates’ and ‘Sent messages’),
rather than trying to introduce something like ‘Send one message’ and
‘Send lots of messages’ later on.
There are some teams who send jobs on a daily/weekly basis. They have
team members who only use Notify for this purpose. So they would
probably benefit from basic view, because they don’t need to see the
dashboard.
This commit:
- adds a new item (uploaded files) to the basic view navigation for
teams that have sent at least one job
- makes the job pages visible to basic view users
I think we should do this now, rather than as a later enhancement to
basic view. We only have one chance to announce the feature, so teams
who do send jobs may otherwise discount it as not useful for them and
the opportunity to have them use it is lost.
Sometimes when setting up a service you might have a few very similar
templates, in which only a small amount of content. Or you might even
have a few of services, which are used by different teams but have
similar templates.
Copy and pasting, especially from one service to another, is a pain.
This commit makes it easier by allowing users to copy an existing
template when choosing to add a new one, instead of starting from
scratch.
Upcoming changes to API will mean that by default its
`get_notifications_for_service` DAO function will return one-off
notifications. In most cases this is what we want, but the message log
page should not show one-off notifications. By passing in the `include_one_off=False`
option to API we can ensure that this page will stay the same when API
changes.
We had kept the original platform-admin page at `/platform-admin` and
created a new page, `/platform-admin-new` for the new platform admin
page. Now that the numbers on both pages look ok we no longer need both
pages, so can replace the original page.
There was a bug where caseworking users skipped the part of the invite
flow where their invite was cleared from the session. This caused
a 500 if they later tried to create another service.
This commit makes sure that both types of user have the invite cleared
from the session after accepting it.
This commit changes the form that the user sees when inviting or editing
another user, if the service has the ‘caseworking’ permission set.
This will allow creating a new type of user, one who only has the
`send_messages` permission, without the `view_activity` permission.
We are doing this because we think there are a number of services with a
lot of users who don’t need to see the dashboard, or the other team
members, and that we can make a simpler interface for these users.
We’ve had a user who’s said:
> Seems configured callbacks cannot be removed once they’re set as the
> fields have a presence check. Is that intentional?
This means it’s not working as they expect. Rather than have to go and
change stuff in the database for them, let’s make it work as they’d
expect.
Only lets you clear the form if you remove both the token and the URL.
If a template has a placeholder like `((email address))` then the sample
spreadsheet and CSV file have the email column twice.
Trying to upload this spreadsheet will result in a ‘duplicate column’
error.
This commit fixes it so that the column will only appear once.
usage page used to make the assumption that the first row of the usage
stats would always be SMS. This now isn't always the case, so make sure
when working out the rate, it only looks at sms rows. Specifically, it
takes the rate from the first stats row. This makes a big assumption
that all the rows will have the same rate per financial year.
we're not actually looking at the detailed service aspects - just
the stats. We're doing this in three places:
* dashboard
* notification activity page
* when checking jobs to see if we're over the daily limit
change these places to use a new api endpoint (service/id/statistics),
which hopefully be a little more performant, and will definitely be a
little more organised - moving away from generic endpoints with loads
of optional parameters.
We still need the detailed endpoints for the platform admin page tho.
Depends on https://github.com/alphagov/notifications-api/pull/1865
tests weren't patching out create_event (which is invoked every time a
user logs in). This was getting caught by our egress proxy on jenkins.
We didn't notice because the event handler code was swallowing all
exceptions and not re-raising.
This changes that code to no longer swallow exceptions. Since we did
that, we also need to update all the tests that test log-in to mock
the call
For both SMS senders and email reply to addresses this commit adds:
- a delete link
- a confirmation loop
It doesn’t let users delete:
- default SMS senders or reply to addresses (they always have to have
one)
- inbound numbers
It assumes that the API will allow updating of an attribute named
`active` on the respective database rows. It could work in a different
way. We can’t do complete deletion though because these will still be
keyed to notifications.
Storing things in the session is proving buggy – we still have one user
(that we know about) where the session data isn’t getting written, so
they’re blocked from uploading a file.
Since all the info we’re storing in the session is about the file, it
makes sense to store it with the file.
This commit only does the writing of the metadata, once we’re sure this
is working we can do subsequent work to read it back, and remove
reliance on the session.
