Do not allow platform admins to:
- create broadcasts
- approve broadcasts
- reject broadcasts
that is, unless they have a send_messages permission
for a given service.
This is so platform admins have the minimum permissions necessary
to cancel a broadcast that might have been sent out accidentally.
How this happens: a user starts to send a letter job, then in another tab starts a SMS
or email job, the sender_id is set in the session. Then the user goes
back to the letter job tab and creates the job. The sender_id is set in
the metadata of the csv file, and causes an exception when trying to persist
the letter notification.
This PR adds a check to ensure the sender_id is not set for letter jobs.
This will catch a small use case where the user has multiple tabs open
and has started sending an SMS or email job, then tries to send a letter
job.
For someone who has retrieved a template ID from their system the only
way to find it in Notify is:
- hack the URL
- click through every template, visually inspecting the ID shown on the
page until you find the right one
Neither of these is ideal.
This commit adds searching by ID, for those services who have an API
integration. This means we don’t need to confuse teams who aren’t using
the API by talking about IDs.
This is similar to how we let these teams search for notifications by
reference[1]
1. https://github.com/alphagov/notifications-admin/pull/3223/files
> Rule of three ("Three strikes and you refactor") is a code refactoring
> rule of thumb to decide when similar pieces of code should be
> refactored to avoid duplication. It states that two instances of
> similar code don't require refactoring, but when similar code is used
> three times, it should be extracted into a new procedure
– https://en.wikipedia.org/wiki/Rule_of_three_(computer_programming)
Two reasons to not hide rejected broadcasts:
- if a broadcast was rejected by mistake then it’s useful to have an
audit of who did that
- it means you can still see old broadcasts without having to leave
in pending-approval, which is dangerous because they might
accidentally be approved
The API has a method to handle setting the default SMS free allowance. This will save a call to the API and remove some code duplication between the two apps.
Needs to be merged after https://github.com/alphagov/notifications-api/pull/3197
When dates chosen for billing report are not in the same
financial year, API throws an error. This error was not being
caught so far. This PR starts to catch it and display a banner
with error message on the page, instead of page crashing.
now that we no longer set it since
https://github.com/alphagov/notifications-admin/pull/3841 was merged, we
don't need to remove it either. And we can remove checks that expect it
when cleaning up the session. And the unit tests that make sure we
ignore it if it's in the session.
So long, session['invited_user'] and session['invited_org_user']!
the invited_user objects can be arbitrarily large, and when we put them
in the session we risk going over the session cookie's 4kb size limit.
since https://github.com/alphagov/notifications-admin/pull/3827 was
merged, we store the user id in the session. Now that's been live for a
day or two we can safely stop putting the rich object in the session.
Needed to change a bunch of tests for this to make sure appropriate
mocks were set. Also some tests were accidentally re-using fake_uuid.
Still pop the object when cleaning up sessions. We'll need to remove
that in a future PR.
We used to upload this to performance platform to show the list of
services and organisations.
There is no longer a performance platform to upload this file to.
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.
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
🚨 Do not merge until after 1 April 2020 🚨
Once this date has past we no longer need to give any services the
previous allowances, so we can remove them from the codebase to avoid
confusion.
It’s possible we change the allowance structure again, but it might
change in a way that this config-based logic doesn’t account for (what
if we did a per-organisation allowance for example). Having both years’
allowances in the config was a quick fix, not a foundation to build on.
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.
Sometimes we get a service ID from a support ticket or a Slack
discussion. Rather than having to hack the URL, this PR augments the
‘Find services by name’ page to support service IDs. If a UUID is
entered, it assumes that it’s been given a service ID, and redirects
straight to the dashboard for that service, without showing any search
results (a complete UUID would never match multiple services). If the
UUID is not a service ID, the user will get a 404.
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).
WTForms now renders the `required` attribute if there is a validator
such as `DataRequired`. This was flagged in an accessibility audit as
being unnecessary since it doesn't conform to the Design System
recommendations, which state that "all form fields are considered
mandatory when navigating a government service unless otherwise denoted
by the word ‘(optional)’."
This uses the approach here https://github.com/wtforms/wtforms/pull/361
to overwrite the `render_field` method.
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.
