The performance page expects all live services to have an organisation.
This should be true on production, but it isn’t always the case in
other environments.
When the organisation name is `None`, the frontend can’t sort the list
of organisations alphabetically and so raises an exception.
first of a two step process to remove invited user objects from the
session. we're removing them because they're of variable size, and with
a lot of folder permissions they can cause the session to exceed the 4kb
cookie size limit and not save properly.
this commit looks at invited org users only.
in this step, start saving the invited org user's id to the
session alongside the session object. Then, if the invited_org_user_id
is present in the next step of the invite flow, fetch the user object
from the API instead of from the session. If it's not present (due to a
session set by an older instance of the admin app), then just use the
old code to get the entire object out of the session.
For invites where the user is small enough to persist to the cookie,
this will still save both the old and the new way, but will always make
an extra check to the API, I think this minor performance hit is totally
fine. For invites where the user is too big to persist, they'll still
fail for now, and will need to wait until the next PR comes along and
stops saving the large invited user object to the session entirely.
This uses the existing endpoint so it matches what’s on the homepage.
It will be more up-to-date than the list of services, but no-one’s going
to be adding things up to check they match exactly.
This matches the existing performance platform page, and I think is a
bit easier to read for high-level numbers where you don’t need to see
that they’re changing second-by-second.
There’s no useful information in the page for the future financial year
because there’s no way for any of the services to have yet used
anything.
Changes this matches the change we made to the service usage page in
https://github.com/alphagov/notifications-admin/pull/3439/files
It would have given the wrong answer for the first hour of the 2021
financial year.
This was OK before, because we didn’t need this kind of precision. But
now it could mean someone signing up in the middle of the night getting
the wrong free text message allowance, so we should fix it.
We’re going to have different allowances next financial year. This means
that when someone adds a service, we’ll need to check which year it is,
so we can give them the right allowance.
This commit changes the config structure so that the current allowances
are explicitly assigned to the 2020/21 financial year.
It freezes the tests to the 2020/21 financial year, so they won’t start
failing automatically when next financial year comes around.
This adds an audit event to the `events` table when the broadcast
permissions for a service (the service mode, channel or provider
restriction) changes.
The fieldset that wraps the collapsible checkboxes
has an aria-describedby to make the summary its
accessible description.
This needs to point to the id of the summary but
the summary didn't have one.
These changes add the id and fix a fixture in the
tests for this module.
The links in the blue boxes on the job page needed hidden text so that
they work out of context. This changes the text from "10 sending" to "10
sending text messages" (with the message type hidden text).
All services have the `upload_document` permission now, so we don't need
to check for it on the email formatting page. This also deletes a test
which is not needed now.
Moves a commonly used fixture into
`mock_get_service_settings_page_common` so we don't need to keep writing
it every time.
Note, we may be able to do similar in the future with
- single_reply_to_email_address
- single_letter_contact_block
- single_sms_sender
but need a bit more thought about fixing tests that would fail due to
this change and need tweaks to the order of their arguments.
Note, no option at the moment to set the service broadcast account type
as None, or back to without the broadcast permission. This has been done
for speed of development given the chance of us needing this is very
low. We can add it later if we need to.