> Once an inbound message has been received, there should be a way to
> see the other messages in the system from the same service to the same
> number. Both in and outbound. Nice inbox/whatsapp stylee view or some
> such. This way the context of the reply is understood.
>
> Initially will only see the outbound template, not the actual message,
> but we’re going to change this for the rest (soon), so that you can
> always see the full message for all outbound.
This commit adds two things:
a section on the dashboard to show how many inbound messages the
service has received in the last 7 days, and how recently an inbound
message has been received
---
Doesn’t show the contents of any messages, just like how the rest of the
dashboard is an aggregation, never individual messages.
a page to show all the inbound messages the service has received in
the last 7 days
---
This shows the first line of the message. Eventually this will link
through to a ‘conversation’ page, where a service can see all the
messages it’s received from a given phone number.
If clicked you will be prompted to enter a sms sender number, when setting the permission on or off.
Team members will always be able to see the number, but will only be able to change it if the inbound_sms permission is off.
Does two main things:
- defines what ‘brands’ we support, in terms of the ID that DVLA use
- adds a form to choose which branding a service uses (currently
platform admin only, like email branding)
By doing this we will be able to (with some more work) preview and send
letters with a variety of different branding.
Story: https://www.pivotaltracker.com/story/show/143506905
no actual template functionality yet - just the ability for services
that have letters enabled to edit a 10 line block that will go on the
top right hand side of their letters with contact information
The previous, weekly activity breakdown was what we reckoned might be
useful. But now that we have people using the platform it feels like
aggregating a service’s usage by month is:
- matches the timeframe users report on within their organisation
- is consistent with the usage page
And like the usage page this commit also limits the page to only show
one financial year’s worth of data at once (rather than data for all
time).
This commit also makes some changes to the jobs view code so that our
aggregation of failure states is consistent between the dashboard pages
and the jobs pages.
Right now we tell people that the usage page is for the current
financial year. This is a lie – it’s for all time.
So this commit calls through to the API to get the stats for (by
default) the current financial year.
We already do this for the monthly breakdown, this just does the same
thing for the yearly totals.
It also adds navigation to show the data for other financial years:
- previous so you can go back and see your usage and verify that the
bill you’re about to pay is correct
- next so that you can check what your SMS allowance is going to be
before you actually get into it
There is a check that the template can not be created as priority if the user is not a platform admin.
There is a check that the template can not change the `priority` unless they are a platform admin.
* all current invocations of get_services now call get_active_services
EXCEPT for platform admin page (where we want to see inactive services
* cleaned up parameter names and unpacking (since *params is unhelpful)
* fixed incorrect kwarg name in conftest
Basically:
- shows all the months from start of given financial year to now or end
of given financial year (whichever is earliest)
- shows a breakdown of free and paid text messages for each of these
months
Depends on:
- [x] https://github.com/alphagov/notifications-api/pull/699
Services who are in alpha or building prototypes need a way of sending
to any email address or phone number without having to sign the MOU.
This commit adds a page where they can whitelist up to 5 email addresses
and 5 phone numbers.
It uses the ‘list entry’ UI pattern from the Digital Marketplace
frontend toolkit [1] [2] [3].
I had to do some modification:
- of the Javascript, to make it work with the GOV.UK Module pattern
- of the template to make it work with WTForms
- of the content security policy, because the list entry pattern uses
Hogan[1], which needs to use `eval()` (this should be fine if we’re
only allowing it for scripts that we serve)
- of our SASS lint config, to allow browser-targeting mixins to come
after normal rules (so that they can override them)
This commit also adds a new form class to validate and populate the two
whitelists. The validation is fairly rudimentary at the moment, and
doesn’t highlight which item in the list has the error, but it’s
probably good enough.
The list can only be updated all-at-once, this is how it’s possible to
remove items from the list without having to make multiple `POST`
requests.
1. 434ad30791/toolkit/templates/forms/list-entry.html
2. 434ad30791/toolkit/scss/forms/_list-entry.scss
3. 434ad30791/toolkit/javascripts/list-entry.js
4. http://twitter.github.io/hogan.js/
The clients never get passed useful values to their `__init__` methods.
Rather the real values are passed through later using the `init_app`
method.
So it should be an error if the client is relying on the values that
get passed to it’s init method. Easiest way to ensure this is by making
the `__init__` method not expect any arguments and passing fake values
to the `Super` call.
We changed the `update_service` method to only update indivdual
attributes of a service, and only allow it to update specified
attributes: 0cfe10639a
We neglected to specify `research_mode` as one of the allowed
attributes.
This broke the app’s ability to put a service in or out of research
mode.
This commit:
- makes sure the tests cover this eventuality
- fixes the bug by specifying `research_mode` as one of the allowed
attributes
Mutating dictionaries is gross and doesn’t work as you’d expect. Better
to have the function return a new dictionary instead.
Means we can be explicit that `created_by` is one of the allowed params
when updating a service.
To prevent typos and inadvertently updating something we shouldn’t,
this adds some filtering to the update_service method to make sure it
is only allowed to update certain attributes of a service.
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).
