show_accounts_or_dashboard has logic about where you should redirect
to. If we let it do this, then that's nicer than duplicating its
logic. We found that it wasn't accounting for orgs in redirects
properly.
If you have a placeholder called `((phone number))` in your email
template, and you try to send a one-off message then the form input will
attempt to validate your ‘phone number’.
This is not helpful if you’re trying to put a landline number in your
email, for example.
This only affects messages being sent through the one-off interface.
This commit makes the form be aware of template type, which fixes the
problem.
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.
it was only used by the choose service page, and then only in kludgy
ways (eg: creating a list containing one item called "add service"),
so lets rip it out and make this page bespoke. Especially now that it's
changed so much.
if there's a service in the session, go there.
if there's an org in the session, go there.
if the user has one service and no orgs, go there.
if the user has one org and no services, go there.
else go to choose service page
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.
this endpoint should probably only be used for the choose-service page
also create an OrganisationBrowsableItem to aid rendering of them
in the front-end.
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.
`<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 get notifications endpoint needs the template_type for search. The inbox page for inbound sms messages was not passing that through, which caused a 400 response.
This resolves that by passing the template_type to the api.
