We’ve moved away from using the expand/collapse pattern on the page
where you click ‘send’. Instead we’re putting the send button in the
sticky footer.
So it’s a bit jarring to still have the expand/collapse on the page you
see after you’ve sent an email. This commit replaces it with the sticky
footer as well.
This is only relevant for emails because:
1. Text messages are generally short enough to fit on the screen
2. We don’t show the status of letters because they don’t really change
We reckon it’s jarring to have the search box appear and disappear as
you navigate through the folders.
Instead it should appear whenever your service has more things
(templates or folders) than you can easily keep in your head (let’s go
with 7 for now).
This keeps the bahviour the same for current services that don’t have
any folders.
If the folder is completely empty, always say ‘This folder is empty’, so
we don’t suggest that you can click around and find other things.
If the current view is filtered, but there are templates available in
other filters, say ‘There are no text message templates in this folder’
to make it clear why you can’t see anything.
The search box should only be shown if there are too many items to
quickly scan on the page. This number is judged to be 7; see the
original PR for more context:
https://github.com/alphagov/notifications-admin/pull/1195
This commit makes that logic work in the world of folders, by explicitly
counting the templates shown on the screen, not all the templates a
service has (which may be spread across multiple folders).
It’s weird that this page changes when you click delete – it looks like
you’re going to a different page.
It should feel like you’re on the same page, just with the confirmation
message.
The problem we had before is that the rename form would `POST` to
`…/delete`, which would then delete the template instead of updating
its name.
We can fix this by explicitly setting the `action` attribute on the
rename form to always post to `…/manage`, even if the user is currently
looking at the `…/delete` page.
Because we’re going to use a sticky footer on this page we don’t need
to show the email in its collapsed form. Showing the email is only
needed to:
- fit more things on a page
- make sure a button comes up above the fold (which the sticky footer
will solve)
When we first built letters you could only send them via a CSV upload, initially we needed a way to send those files to dvla per job.
We since stopped using this page. So let's delete it!
If the user is looking at the notifications page for all message types
(which is what we show ‘caseworkers’) then it doesn’t make sense to ask
the API for the data retention period for that message type (because
it will be `None`). Doing so causes the API to return a `404`, which
then causes the admin app to return `404`.
Passing through `None` as the value of limit days will just cause the
API to return everything in the `notifications` table, which is fine
for us.
Some users are bookmarking the sign in page for quick access to their
Notify service.
If they’re already signed in when they used this bookmark they get
redirected. However the redirect isn’t very smart, because it just takes
them to their list of services. This isn’t great if they only have one
service.
This commit redirects them to the `show_accounts_or_dashboard` endpoint
instead, which does the work to figure out which page is most useful
to show someone when they sign in.
Also changing this for `/register`, although it’s less likely that
someone will have bookmarked this page.
Often people will be editing the existing name, not changing it
completely.
This matches what we do when someone wants to rename their template or
service.
In multiple user research sessions we’ve noticed people edit the
auto-generated template name to put something at the end of it.
This is fiddly because of the quotes we put around the name:
> Copy of ‘Exiting template’
It also means that if they keep our prefix then the template doesn’t
sort alongside the one it’s replacing.
This commit changes the name of copied templates to better match the
behaviour our users are showing.
Also adds a bit of auto numbering, just as a nice detail.
A folder is relevant if it, or any of its descents contain a template of
the kind you’re looking for.
If you’re not filtering by template type then you should see all
folders.
- Add a GET / POST view: manage template folder
- Add a template for that view, where a user can rename their
folder
- Add an API client method for updating a folder
- Test the new feature, including the test that service without
permissions cannot manage a folder
Follows what we’re doing with the folders stuff. Avoids having too many
very straightforward methods on the model. Especially when the data they
need is only used by the form. So it’s better to encapsulate the logic
in the form.
It’s redundant to make two API calls here, one to get all keys and one
to get a single key. Since the API calls are sequential we can speed
things up by getting the one key from the list of all keys.
Currently, a user can select a reply-to email address or text message
sender when uploading a CSV file but this is ignored and the default is
always used instead. As a first step towards changing this, this adds
the sender_id (if selected) to the S3 metadata so that this information
can be used when processing the job.
If the browser posts the value of `<input value='None'>` to the server
it does so as a string.
We want to post a value of `None` (actually JSON `null`) to the API. To
do this we:
- set the value in the form class to `'None'` (ie a string)
- convert to `None` (as a type) afterwards
However seeing `x = 'None'` in code looks a bit like a mistake. So to
make sure it looks deliberate and clear what is happening this commit:
- makes a reusable constant for `'None'`
- adds a comment explaining why it’s a string
This commit adds logic to:
- take the list of selected folders and templates
- split it into two lists (of folders and templates)
- `POST` that data to the API, to effect the movement of said folders
and templates
I’ve tried to architect it in such a way that we can easily add more
template ‘operations’ in the future, as we add more forms to the choose
template page.
This commit adds:
- checkboxes to let you select a template or folder
- radio buttons to let you select where to move those template(s) and/or
folder(s) to
It only does the `get` part of this work; handling the `post` and
calling API will be done in a subsequent commit.
This has two advantages:
- less logic in the view
- lets us filer the available navigation by which channels (email, text
letter) a service has available
