With the upgrade of pep8 to 1.7.0 module imports are required to be at the top of the file,
meaning I had to add a noqa line to some of the init files. Are those init files wrong or is pep8 too strict.
> We show the last weeks template usage on the dashboard, which is
> great, but if you're looking for longer term trends, you're out of
> luck...
> So, let's let you see more on a more detailed page (linked from the
> dashboard). Initially this should just show you all templates that you
> have used ever and the count for each. Order same as dashboard, most
> popular first.
https://www.pivotaltracker.com/story/show/117614585
Previous the table of templates on the dashboard was for all time.
This commit uses the `limit_days` parameter of the API endpoint to only
show template usage from the last 7 days, aligning with the big numbers
shown above.
We want to align all our stats to be for the last 7 days.
This means summing up the stats response from the API to make the Big
Number. Previously the big number was counting sent notifications as
successful. This commit changes it to only look at delivered
notifications.
Right now, the API doesn’t have a way of filtering to only show the last
7 days. So for the moment the dashboard will show statistics for all
time.
The upshot of this is that we can link from the dashboard to the
activity page when there are failures.
For users who:
- want to send messages from a template
- want to edit templates
For developers:
- who need to get the ID of a template
This commit mainly cleans up the choose template page so there are less
options, and the options that are there are less wordy.
This means:
- moving ‘send yourself a test’ onto the send messages page, and making
it button
- stripping a lot of stuff out of the ‘send from API’ page, so it’s more
obvious what the template ID is
When you add a new service, it’s probably the one you want to do stuff
with.
When you get invited, the service you’ve been invited to is probably the
one you want to use.
This commit adds the ID of the new service or service you’ve been
invited to to the session.
There’s no content in the tour that’s specific to a service. And since
we can now take a pretty good guess at what service you last used, or
which service we should send you to if you only have one service,
there’s no need to make the URLs for the tour service-specific.
This also means that you don’t need to be logged in to see the tour
pages, and we have no good reason to only restrict these pages to users
with accounts.
https://www.pivotaltracker.com/story/show/116960703
This commit replaces the old _API Documentation_ page with the Markdown
version that Catherine has been working on.
I’ve checked that there’s nothing obviously wrong or placeholder-y still
in there, so I think we’re good to go.
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
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.
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
> 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
Template stats should show the most-used template first.
This commit:
- re-writes the `aggregate_usage` function to use `itertools.groupby`,
which can do aggregation, and can return data in a structure that’s
easy to sort on
- uses generators so that we’re not keeping lots of rows of template
stats in memory
https://www.pivotaltracker.com/story/show/117348893
We’ve seen in research that people can be reticent to give their real
phone number. Telling them that it will be used for something should
help (ie we’re not just collecting it for marketing).
This also rewords the other form hints on this page to be less computery
because we haven’t looked at them in aaaages.
We probably shouldn’t hide the contents of the CSV when people are just
testing the app, or if they’re starting off with small jobs.
A limit of 15 rows displayed was awkwardly on the cusp between just
testing and sending a small batch.
This commit increases the limit to 50; I reckon that over 50 recipients
no-one will be wanting to check them all individually.
> If a user tries to save a template containing something like
> ((name,date)) we should give a validation error.
This is because it causes havoc with the column headers in CSV files.
https://www.pivotaltracker.com/story/show/117043389
