We shouldn’t tell people on one page (the terms page) that we know about
their organisations agreement and then on the pricing page tell them to
contact us to find out what we know about the agreement.
So this commit adds the same logic from the terms page to the pricing
page, with wording that makes sense in the pricing context.
People are emailing us asking if their organisation has signed the
agreement. In some cases they have, so this is a waste of their and
our time.
This commit adds a bit of logic to the terms of use page to tell users
when their organisation has already signed the agreement.
`<h1>`s should be unique across the site. This page’s `<h1>` matches
that of the previous page (the one with the checklist).
This commit re-titles it to:
- be unique
- more accurately describe the content of the page
This question was designed to make people feel like it was OK to submit
their request without getting the MoU signed. We reckoned that this was
the fastest way of getting their service live (because the MoU is the
bit that’s most likely to slow them down).
We now have a better way of telling people:
- if they’ve signed the MoU already
- or to contact us if they haven’t (which is what the majority of teams
seem to do now)
We were never actually using the answer to this question – we were still
checking for every service whether they had it signed.
So this commit removes this now-redundant question.
We have teams who are using the dashboard every day, and being
confronted with this alarming yellow banner. There’s no action they need
to do since they’re only looking at the messages sent.
So this commit removes that banner from the dashboard. It also removes
the CSS and HTML for it from the app entirely because this is the last
remaining place we were using this style of banner.
If someone has no permissions but needs permissions the thing they’re
probably going to need is to send a message or edit a template.
The place they will probably come to is the place where the buttons
would be – users with these permissions are finding the thing they need
to do on this page.
So this commit adds a line to this page which (hopefully) makes it clear
they’re in the right place, but need to go and speak to someone.
* HM Courts and Tribunals - HM Courts & Tribunals Service
* Leicester City Council - Leicester City Council
* Divorce Service Line - HM Courts & Tribunals Service
* Jury Central Summoning Bureau - Ministry of Justice
* ISU - Pembrokeshire County Council
* ESFA pre-16 funding - Department for Education
* ONS Business Continuity Alert System - Office of National Statistics
* HMPO Business Resilience Team - Home Office
* Rugby Borough Council - Rugby Borough Council
* Common Platform - HM Courts & Tribunals Service
The email template does this already when formatting the body of the
message. But the spreadsheet preview doesn’t, which means you get lists
like:
- thing
- thing
- None
This commit fixes that.
This was a pre-existing bug, but gonna roll it in with this PR.
For text messages/emails it makes sense for ‘sending’ to be gray and
‘delivered’ to be black. But since we don’t show sending/delivered for
letters it doesn’t make sense for the text to change colour.
we branch on any_ to either say "require ALL these permissions" or
"require ANY of these permissions". But we only ever call the decorator
with one permission, or with any_=True, so it's unnecessary
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.
when added to a service, all users are given the view_activity
permission. So, if that's included in the list, we don't need `any_`,
and we don't need any of the other permissions.
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.
If someone has duplicate recipient columns in their file we don’t know
which one to use. This commit adds an error message which should help
them fix the duplication.
This commit doesn’t go to the extra effort to actually show the
correct values for duplication in the preview. Don’t think it’s worth
the effort/complexity for how infrequently we’ve seen this error.
Depends on:
- [ ] https://github.com/alphagov/notifications-utils/pull/376
