These make space for the folder icon using
padding-left when they have ancestors as they are
inline so it only effects the line the first link
is on. Without ancestors they are block-level so
padding-left pads the whole block.
We had a block of CSS that fixed this, by using
text-indent for those without ancestors but the
selector was broken by changes to the HTML (it was
no longer the :first-child).
This uses the :first-of-type pseudo-class instead
to ignore preceding elements of different types.
Also includes changes that move styles for links
out from under elements with a class of
.message-name, which was removed in the previous
commit.
When sending from an uploaded CSV `.send_messages` now puts the filename
in the metadata. It previously used the query string to pass the
filename to `.check_messages`, where it can be lost.
The `.send_from_contact_list` function redirected to `.check_messages`
with `original_file_name` in the query string. Contact lists already
have `original_file_name` as part of their metadata, so we can stop
sending it in the query string and use the metadata instead.
We were passing `original_file_name` from the `.upload_contact_list`
view function to the `.check_contact_list` view function as a query
param. We now store it in the metadata instead. `.check_contact_list`
still checks for `original_file_name` in the query string if it's not in
the metadata - this is necessary until the code has been deployed for a
few days and we can be sure that there are no contact lists that are
mid-way through the upload stage.
You might alternate between training mode and live mode. It’s not like
normal Notify where you start in one mode and then transition out of it
– which is what ‘still’ implies.
If a subclass of `JSONModel` defines a property then we shouldn’t try
to override it with the value from the underlying dictionary.
Rather than silently fail we should raise an exception because it will
help keep our list of `ALLOWED_PROPERTIES` nice and tidy.
I'm mainly making this change because it's useful
for the CSS that styles the hint text when the
link is focused for the link to have no parent
container.
That being said, there isn't really enough content
underneath these headings to justify them as it is.
I've wrapped them in a list instead because:
- they're structured like a list
- we already called them a `template-list`
This commit also replaces the `message-type` class
on the paragraph below where the headings went,
for consistency. It also removes the CSS for that
class as I couldn't find anywhere else that used
it now.
Template list items without checkboxes use the
`.message-name` and `.message-type` classes for
their links and hints.
This means styles used to expand the focus area
previously are clashing with the new approach.
This removes the old ones and gives
`.message-type` paragraphs a non-static position
to give them a z-position and so raise them above
the expanded link area.
The font-size goes down to 16px on mobile. This
changes the line-height too which makes it too
small. This bumps it back up the be the same as on
desktop which makes space for the icon (if a
folder) and gives the link more space.
Also reduces the horizontal space between the icon
and its link by the same amount the font-size
changes.
When the list of areas is restricted to half the width of the page it
starts to look pretty higgledy-piggledy when you have lots of areas or
areas with very long names.
To do this I’ve ripped out the table markup in favour of headings,
paragraphs and lists. Probably pros and cons for each, but it was really
hard to do the layout with the content in a table.
For emails and text messages we sort by the time the user (or API) sent
them.
This makes sense for broadcasts too, since most users will receive the
alert within seconds of it being broadcast.
For alerts that haven’t started yet we can sort by `updated_at`, which
is when the user preparing the broadcast submitted it for approval.
Now that pending alerts aren’t in their own section there’s nothing to
label them as pending. So this commit replaces the extra metadata we
show for a pending alert (the name of the person who created it, which
was only ever a reckon) with an explicit label that says it’s waiting
for approval.
Splitting the dashboard into multiple sections was confusing, and people
sometimes mistook the headings as labels, especially when a section was
empty. It just wasn’t clear what the hierarchy of the page was.
This commit combines the current and pending broadcasts into one list
on the dashboard. Previous broadcasts have already moved to their own
page.
If you refresh the page on a current broadcast while someone has
cancelled it you’ll see the wrong navigation item selected. This commit
adds redirects to take you to the correct endpoint in these edge cases.
Once a broadcast has been submitted for approval it either lives on the
‘Current alerts’ or ‘Previous alerts’ page, depending on where it is
in its lifecycle.
Therefore when clicking into a broadcast from one of those pages the
same navigation item should remain selected.
Because we select the navigation items based on the request endpoint,
this means we need an endpoint for each navigation page, even if the
content of the pages will be the same in both cases.
This commit adds the two new end points, removes the old, single
endpoint and updates links to point to the new endpoint.
This bit of code is just a safety check to make sure we don’t
inadvertently updating something we shouldn’t (see
0cfe10639a for context).
`rate_limit` is something we allow the admin app to update now (as of
939029a9be).
