This makes a couple of changes:
- Most importantly, it wraps the setup code in a conditional so that
developers don't need to have a DSN set to start the app locally.
- Secondly, it removes the redundant call to "set_level". Originally
I thought the integration was sending info/warning events, but this
isn't the case [1] and even if it was, "set_level" affects the level
of custom events [2], not the level they are dispatched at.
[1]: 4c09f3203d/sentry_sdk/integrations/logging.py (L56)
[2]: https://docs.sentry.io/platforms/python/guides/logging/usage/set-level/
This updates the `get_notifications_for_service` of the
`NotificationApiClient` to make POST request to the api when the `to`
field is provided. This is done so that we avoid logging personal
details such as email addreses.
If the `to` field is not present, the method will make a GET reqeust and
there will be no change to how it works.
Otherwise we start spamming Sentry with every 404 error log. Even
if the erorr is a 5xx, it depends on how we handle it in the calling
code as to whether we would want to consider it an error.
I didn't spot this in initial testing on Preview because the 404s in
Preview are only triggered due to the functional tests, which only run
when we're deploying something.
Arguably we shouldn't be logging at error level in our Python Client,
since we're also raising an exception [1]. But changing that would be
a can of worms as it's not an internal-only library.
[1]: 74a958de00/notifications_python_client/base.py (L118)
This will capture and send various events to Sentry:
- Any unhandled exceptions.
- Any logger.error calls.
- Some request traces.
The latter are severely limited to avoid going over the free tier
limits for Sentry, and to avoid excess effort on our end.
If an organisation doesn’t have any live services then there’s no data
to download. To make things less confusing we should hide the link in
this case.
This commit also modifies the existing test so that the assertions are
consistent.
While the package can always fetch new holidays via the GOV.UK API,
the latest version of the packages also caches ones for next year,
which means we can avoid unnecessary web requests.
We can't assign `hscni.net` to an organisation because it is used
by GP surgeries, so we don't always know which org it should be
associated with. This change allows people with the an `hscni.net`
email address to sign up and create a service.
If the organisation table contains an entry for `agreement_signed_by_id`
and for `agreement_signed_on_behalf_of_name` then we should the person
who signed the MOU as being the `agreement_signed_on_behalf_of_name`.
This was wrongly showing the `agreement_signed_by_id` as the person who
signed the agreement.
We use the `ChangeEmailForm` if you want to change your own email
address or someone else's email address. This has various validators
which get run. We check if the email address is valid (by using a
function from utils) and if the email address is already in use
(by calling API).
If the email address is not valid, we should not call API to see if it's
already in use because this will cause an exception in API leading to a
`500` in admin. We now only call API if there were no other errors with
the email address.
(The `test_should_redirect_after_name_change` test didn't need the
`mock_email_is_not_already_in_use` fixture, so this has been removed.)
This brings a few performance improvements for RecipientCSV, which
we use to preview and process CSVs. One change also renames one of
the attributes for the class to "guestlist".
We don't currently have any radio fields or check boxes where it's
possible to get more than one validation error. However, since we
never want to show more than one error at a time for a field, this
changes the error messages for the relevant widgets to only show the
first error if there ever were multiple.
If there were multiple errors, this widget was joining the messages
together and displaying all error messages. If a text input field does
have more than one validation error, we only want to show one.