Use the new version of the notifications-python-client. This version no longer adds the req and pay to the claims of the jwt.
The change is backward compatible so an older client that sends a JWT with the extra claims will pass authentication.
Once all the clients have been updated to not include the extra claims some updates to exclude them from the method signatures will happen as well.
The documentation has been updated to reflect this change.
https://www.pivotaltracker.com/story/show/116971293
If the hint aligns with the message body then it looks like you can only
add placeholders to the body. This commit aligns it with the subject
instead, and since it overlaps both it looks like you can add
placeholders to both (hopefully).
This commit makes the placeholder hint not be dependent on their only
being one textbox with placeholders on a page.
To do this it needs to be its own module, because the two textboxes are
each self-contained instances of the same module.
The way I’ve gone about this is to make the placeholder hint accept a
list of textboxes it should look in when deciding what message to
display to the user.
Most of the code is extracted from the existing placeholder highlighting
module.
At two lines the subject textbox was expanding even when it was empty.
This commit makes the distance at which textboxes start expanding less
sensitive.
In order for subject lines to have their fields highlighted they have to
be textboxes. This is because the highlighting script only works with
textboxes that don’t scroll, either horizontally, vertically, or be
keying through them.
I think this was used for the invite page at one point, but isn’t now.
Generally at GDS we don’t do disabled form controls, they don’t tell you
_why_ they’re disabled.
There is a bug in Babel[1] which means that it throws an exception if
it can’t find the locale it wants to use.
This is not a problem when developing locally, because OS X comes with
lots of locales. The AWS machines, however, only have one locale, which
is not the one that Babel is looking for. Hence the ‘Activity’ page
doesn’t work.
This commit changes to using Humanize[2] instead, which is much less
vast and hopefully less hungry in its requirements.
That’s a morning we won’t get back…
1. https://github.com/python-babel/babel/issues/137
2. https://pypi.python.org/pypi/humanize
Statuses used to be:
- failed
- complaint
- bounce
- sent
- delivered
Now they are:
- sent
- sending
- delivered
This change broke the notifications page on the admin app.
It also made me realise that we should be ignoring ‘sending’ messages in
the history page—it should only show messages we’ve tried to deliver.
The code for this is a bit of a bodge, but it will get things working
again for now.
Means you can see, for example emails that have failed.
Means adding:
- logic to generate links which can have a type parameter, a status
parameter, or both
- a ‘pill’ UI component for seeing which filters you currently have
applied
- some logic to change the page title based on which filters you have
applied
This table had a lot of columns, which meant that some of them became
very narrow, wrapping the text awkwardly.
This commit groups some of the data into a chunk, which occupies the
first column.
If you put, for example, a URL in an email template it can be very long.
This can cause it to overflow its container. This commit forces it to
wrap instead.
We should (and do) keep exact copies of SCSS files that have come from
elsewhere so that we can easily upgrade them. But sometimes they don’t
always pass our linting rules, or throw a lot of warnings, which is
noisy.
This commit:
- moves such files into their own subdirectory
- tells SCSS Lint to ignore files in this directory
> At the moment, we have an all email templates page, and an edit an
> individual page.
>
> This gets messy when we refer to templates like the dashboard and the
> activity views. We solve this currently by using anchor links to the
> list page, but this is clunky.
>
> So lets add it, then update the links on the dash and activity to the
> new view page.
>
> Should be a link from the view a single template page, to the template
> hub page.
https://www.pivotaltracker.com/story/show/117349227
It’s a bit silly to have email templates expandable if you’re only going
to reveal a couple more lines.
This commit adds a data attribute which specifies how high (in pixels)
the email template can be before it gets truncated. It then changes the
script to only truncate emails which are naturally taller than this
height.
Currently the cut off is at 200px, which is approximately 8 lines of
text: `200px / (font-size: 19px * line-height: 1.31) = 8.03`
