Since platform admins can use the new settings page, this commit:
- links to that page
- removes the platform-admin-only endpoint that switches basic view on
and off
This commit adds:
- a row to the settings page…
- …which links to a page explaining what basic view is
The new row (and link) will only appear for services who already have
the feature switched on. This is because we are not launching the
feature yet, so it shouldn’t be available to just anyone.
Often we show/hide these rows based on what permissions a service has.
This commits refactors that check into a reusable macro, rather than
having to write the same `if` statements all the time.
‘Caseworker’ was a bad name because it:
- suggested that Notify might be expanding into case management
- may or may not map to someone’s actual role, in a confusing way (this
is why ‘manager’ is also a bad name)
‘Basic view’ is the best name we could come up with because:
- it describes the purpose of feature, not the user
- a ‘view’ changes what you can _see_ as much as it changes what you can
do
Admin remains a good word – in research users self-describe their use
of Notify in using it. This commit makes the name ‘admin view’ to match
‘basic view’.
This also means we can hide the legend for this fieldset because the
choices are self-explanatory.
Eventually the ability to have the caseworking view for your service
will be self-service. But while we’re still building it only we should
be able to enable it, for our own testing purposes.
So this commit adds platform admin functionality to switch the feature
on and off for our services.
The contact link on the settings page should be truncated instead of the
text being wrapped and overflowing on to multiple lines. This adds in an
option to the text_field macro to truncate long text fields. This
setting has been used to truncate the API callback URLs too on the
services/<service_id>/api/callbacks page.
The contact link for the service now gets displayed on the service
settings page if the service has the 'upload_document' permission. There
are no changes to the appearance of the service settings page if a
service does not have the 'upload_document' permission.
At the moment branding is an undocumented feature. We get a bunch of
support tickets from teams asking its possible.
This commit:
- lets people know it’s possible, and what the options are
- is the first step towards making this process as self-service as
possible
In some cases we will be able to infer a user’s organisation from there
email address, and Google image search their logo. So the experience for
them is that they press a button and government just sorts it out for
you (also known as "the dream").
In other cases we will have to get back to people asking for a copy of
their logo, or to find out about their service, but this is what we have
to do at the moment anyway.
Adds a platform admin button to the service settings to turn on/off
'upload_document' service permission. The permission allows uploading
documents to document-download-api through the post notification API
endpoint.
p1 == "should notify team be alerted of this (via pagerduty)"
urgent == "should the user be told we'll look at it"
* If it's in office hours, it's always urgent. It's never a P1 because
we'll notice it anyway
* If it's outside of office hours, it's urgent and P1 if it's severe,
otherwise it's neither
layout as follows
```
ORG_1
SERVICE_1
SERVICE_2
--------------------
ORG_2
--------------------
SERVICE_3
SERVICE_4
--------------------
Add a new service...
```
* org 1 and 2 are organisations that the user has access to.
* Service 1 and 2 are part of org 1, AND the user has access to them.
- There may be more services in org_1 that the user doesn't know
about.
* Service 3 and 4 are services the user has access to.
- They MAY be part of an organisation that the user does not know
about. They can't be part of org_1 or org_2 tho.
rather than allow admins to do everything specifically, we should
only block them from things we conciously don't want them to do.
This is "Don't let platform admins send letters from services they're
not in". Everything else the platform admins can do.
This is step one, adding a restrict_admin_usage flag, and setting that
for those restricted endpoints around creating api keys, uploading CSVs
and sending one-off messages.
Also, this commit separates the two use cases for permissions:
* user.has_permission for access control
* user.has_permission_for_service for user info - this is used for
showing checkboxes on the manage-users page for example
With this, we can remove the admin_override flag from the permission
decorator.
platform_admin is a separate concept to permissions, so by removing the
checks for it from the current_user.has_permissions function, we can
simplify things greatly. We already record on the user whether they're
a platform admin anyway.
Users who have the ‘manage API keys’ permission can see the settings
page. But they don’t have permission to request to go live.
At the moment they can still see the link, though clicking it gives them
a 403 error. This commit changes it so that they can’t see the link, and
tells them who they should speak to about going live (their manager).
Users can choose whether to have these features on or off now. And
a platform admin can still use the same controls to switch the features
on or off on behalf of a user. There’s no need for the separate buttons.
Email auth is a new feature that currently we’ve only given to teams
who have contact us with a problem.
At the moment, we’re aware of all the teams that are sharing phone
numbers when they sign in. We think that in the future there will be
other teams who encounter this problem. So we should let them know that
they should contact us if they are having the problem.
At the moment we want to talk to teams before giving them access to the
feature, so that we’re confident it’s only going to teams from whom it’s
more secure than using a text message code.
* if the service issuing the invite does not have permission to edit
auth types, don't let them do anything. This will stop them turning
existing email_auth users back to sms auth
* if the user hasn't got a mobile number, but the invite is for sms
login, don't do anything either. They won't have a phone number if
they signed up via an email_auth invite previously.
in these cases, we accept the invite and add the user to the service
as normal, however, just don't update the user's auth type.
We’re extracting this from being determined based on what the sender
name is to its own setting.
This commit will let users set it independently.
Until the explicitly set it, it will still be determined based on
whether their default sender name matches the default for the platform.
We used to say ‘None’ if this was empty. Now we say ‘Not set’. The thing
that decides whether to make the text grey or not was looking for ‘None’
(the old thing).
‘Change’ as a label for the link is misleading, because this is also the
page you go to in order to get the ID of a given reply to address.
‘Manage’ feels a bit more general.
We didn’t make this self-service before because the pricing information
wasn’t published (ie we had to send it to services that asked for it).
Now that we publish pricing information in the app, there’s no reason
why services can’t make an informed decision about whether they want
international SMS or not.
So this commit:
- removes the platform admin button
- adds some radio buttons that our users can click with their mice
