‘Upload recipients’ and ‘Send to one recipient’ have always been
slightly clunky phrases.
Now that basic view jumps straight into the ‘Send to one recipient’
flow there’s no way for users to get to the ‘Upload recipients’ flow.
By adding a link to it from the ‘Send to one recipient’ flow it’s
possible for users of basic view to access it.
But we don’t want to introduce too much inconsistency between basic view
and admin view because users will be migrating from one to another. They
might also be talking to their manager, who wouldn’t be able to tell
them where to click if they were looking at two completely different
interfaces.
This also means that we can keep the left-hand navigation in basic view
nice and simple with the two options (‘Templates’ and ‘Sent messages’),
rather than trying to introduce something like ‘Send one message’ and
‘Send lots of messages’ later on.
- corrects target page for set_email_branding to
new preview step instead of itself
- removed check for helper method being called in
email page test
- updates expected result for test of global
headers to include changes to `frame-src`
- updates navigation config with brand preview page
If you have the API keys permission you can see the settings page. But you
can’t change or request stuff, like email branding. So we shouldn’t show the
link that suggests you can.
This is the existing behaviour. It’s broken by this issue in WTForms
2.2.1: https://github.com/wtforms/wtforms/issues/401
This commit hand-crafts the default value, because WTForms is ignoring
the `default` argument on the form object attribute.
Not really sure how this ever worked 🤔
We’re interested to know which services are looking at the basic view
preview (even if they’re not turning it on).
This commit logs their service IDs as events into Google Analytics.
There are some teams who send jobs on a daily/weekly basis. They have
team members who only use Notify for this purpose. So they would
probably benefit from basic view, because they don’t need to see the
dashboard.
This commit:
- adds a new item (uploaded files) to the basic view navigation for
teams that have sent at least one job
- makes the job pages visible to basic view users
I think we should do this now, rather than as a later enhancement to
basic view. We only have one chance to announce the feature, so teams
who do send jobs may otherwise discount it as not useful for them and
the opportunity to have them use it is lost.
Calling `.set()` with `True` stores the byte string `'True'` which
cannot subsequently be decoded from JSON (because boolean values in
JSON are lowercase, ie `true`).
> "normal" is a word that does not really tell much, could we maybe name
> this constant better?
‘Non-scheduled’ more explicitly describes that statues in this set.
Each of these methods does the same thing, so this refactors into an
attribute lookup, which saves writing boilerplate code and makes it
easier to add new properties.
This is better than just keying into the JSON because it means you get
an exception straight away when looking up a key that doesn’t exist
(which via mocking you could ordinarily miss).
Having the service floating about as JSON is a bit flakey. Could easily
introduce a mistake where you mistype the name of a key and silently
get `None`.
Also means doing awkward things like `if 'permission' in
current_service['permissions']`, whereas for users we can do the
much cleaner `user.has_permission()`.
So this commit:
- introduces a model
- adds a `.has_permission` method similar to the one we have for users
The list of services this page was looking at only included those not
belonging to an organisation.
On production this excludes services we’ve added to organisations to
make the management of those services easier (eg ‘GDS’ and ‘DVLA’).
