This was an early reckon feature. There were a few of problems with
it:
- it worked on the service, not just on the API keys as described
- it was back to front, ‘suspending’ a service set `active` to `True`,
reactivating it set `active` to `False`
- no part of the API actually respected the `active` flag on a service
The same intent can be acheived by either:
- revoking an API key
- having a platform admin put your service back into trial mode
So this commit removes the link and the code behind it.
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 you make a ‘normal’ API key it won’t work as described until your
serivce is live.
We should make this clear at the point at which you choose this key.
Slicing was to avoid duplicate items in the list. A more idomatic way
to avoid duplicate items in a list is to use a `set` instead.
The order of the list doesn’t really matter, but it’s a lot easier to
test for if the order is consistent.
The CSV report isn’t very useful until it has all the rows from your
original file. So we shouldn’t show you the link until all notifications
have been created.
Until this point, it’s useful to know how much longer you need to wait,
so this commit adds a percentage count of how much of the file has been
processed.
The difference between created and sending isn’t something a user should
have to care about. So this commit:
- counts created and sending as the same thing
- displays and notifications which have a status of created as sending
Processed is not an easy to understand thing, and the overlap with
sending/delivered/failed is not easy to intuit.
‘Total’ is a much easier concept to grasp (it relates directly to your
file), and it’s less distracting because it doesn’t change.
It’s weird when the sending number ramps up to ~200 or so and then
just floats around as new rows are being added and older ones are being
marked as delivered/failed.
It’s also not great that you don’t know how many rows are in a file, if
you haven’t uploaded it yourself. But the only reason you want to know
this is to know how much work Notify has remaining to do.
So ‘sending’ should start from the total number of rows in the file
and count down.
to help get rid of notification statistics tables, move over the
job page. fortunately its required data format is almost identical
to the return value of the detailed service endpoint, so little
work is required - only to add a sending column
we don't want to use the old statistics endpoints any more
also a couple of quality of life changes
* moves some logic out of the _totals.html template
* tidies up statistics_utils
