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.
We don't want pyup.io upgrading sub-dependencies listed in the
requirements.txt file since it does it whenever a new version is
available regardless of what our application dependencies require.
The list of top-level dependencies is moved to requirements-app.txt,
which is used by `make freeze-requirements` to generate the full
list of requirements in requirements.txt.
(See alphagov/notifications-api#1938 for details.)
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
