also added tests for the various hiding logic points
also added new logged_in_client in conftest - so you dont need to
patch all those stupid API calls for get user and get service
Now that we’ve removed simulated notifications from the dashboard and
activity pages they’re not visible anywhere in the app.
While they should’t be visible to non-technical users, developers have
a real need for Notify to confirm that their code is doing what they
expect. This is needed especially when they’re just getting started with
Notify.
There’s no way of seeing this info from the API either, because a key
can only get notifications created with a key of that type.
It doesn’t make sense to make this a ‘mode’ of the dashboard or activity
because the information about notifications that developers need is
also different. So this commit adds up to 50 of the most recent
notifications sent via the API to the page that developers use as their
‘home’ page.
This also lets us explain the 7 days thing to developers via the
empty slate state of this area of the page.
Other than which services are live it’s also interesting to know what
services are getting created on Notify. So let’s put the newest ones at
the top of the page.
On the dashboard:
- adds a new ‘in the next 24 hours’ section to the dashboard which lists
upcoming jobs
- tweaks some spacing on the dashboard so that it doesn’t look like too
much of a mess
- don’t show scheduled jobs in the table of normal jobs
On the jobs page:
- don’t show scheduled jobs
`status` will be deprecated at some point. `job_status` is what gets
set to `scheduled` to show that a job has been scheduled for some time
in the future.
The job is complete when all notifications are delivered or failed.
The report is complete once we have all notifications are in the
database.
This commit changes the meaning of the percentage from the former to the
latter. This is how it was before we removed the aggregate stats for
jobs.
The service API client was updating every attribute of a service. Which,
while kinda clunky, is fine…
…until something calling it doesn’t pass in every attribute of the
current service. It was then defaulting optional parameters to `None`.
Which resulted in a bug whereby every time a service was set to live,
its `reply_to_address` and `sms_sender_name` got overwritten to be
empty.
This commit changes the `update` method to only require the service ID,
and pass whatever other named arguments it received straight through to
the API. The API handles partial updates just fine (I think).
When we say ‘delivery information is available for 7 days’ you have to
infer _when_ the seven days starts. When you come back to the page it
still says ‘available for 7 days’ even if you only have a day left to
download it. This is confusing.
This commit changes the text to be relative to now, eg ‘available for 7
days’, ‘available for 1 day’.
The date is counted to midnight on the seventh day, which is when the
data is actually deleted.
This commit makes the CSV download use the same language for failure
reasons as the frontend.
It also adds a test around this stuff, which was patchily tested before.
Since you can’t really send or edit a deleted template we should show
a message telling you that the template has been deleted.
This is important because deleted templates still show up in the
template statistics.
Each service on the list is linked to the dashboard page of the service.
The platform admin user can see/edit templates, see/invite users, see/edit service settings.
The platform admin user can not send messages, see/edit api keys and developer docs.
