Settings looked at `domains.yml` when users were making go live requests
or email branding requests.
This will allow us to remove the `domains.yml` file, by using
information about organisations that is now stored in the database
instead.
This is the first step of replacing the `domains.yml` file.
In order to replicate the same functionality we get from the
`domains.yml` file and its associated code this commit adds a
`Organisation` model. This model copies a lot of methods from the
`AgreementInfo` class which wrapped the `domains.yml` file.
It factors out some stuff that would otherwise be duplicated between the
`Organisation` and `Service` model, in such a way that could be reused
for making other models in the future.
This commit doesn’t change other parts of the code to make use of this
new model yet – that will come in subsequent commits.
Dealing with users who request to go live but haven’t completed all the
steps still represents a significant support overhead for our team.
We’ve made some improvements to the percentage of incomplete requests
with a better page design, but ultimately because it still shows the
button people think it’s OK to press the button while some of the items
on the page still say [Not completed].
We can do this now because organisations are in the database, which
means we can mark the agreement signed as soon as we get it back,
without having to deploy code.
We should audit when a service manager changes a user profile that is not
their own. This can be recorded in our events table, which is currently
only used to record successful logins.
This adds two new types of event, `update_user_email` and
`update_user_mobile_number` which store the
- browser fingerprint
- IP address
- user id of the user being updated
- user id of the service manager making the change
- original email address and new email address (for `update_user_email`
events)
- original mobile number and new mobile number (for
`update_user_mobile_number` events)
Shows a count of how many folders that user can see - this doesn't do
anything smart with parent folder stuff, it's just "how many checkboxes
are ticked on the edit page".
* doesn't show if service has no folders
* doesn't show if service hasn't got folder permissions enabled
Data attributes need to be '-' separated strings
in the HTML to appear as camelCase keys in the
`.dataset` (`.data()` in jQuery) property.
This corrects the assumption that the camelCasing
would carry through from the HTML.
More info:
https://developer.mozilla.org/en-US/docs/Learn/HTML/Howto/Use_data_attributes
If users scroll a page with an autofocus component
on so it is off-screen it seems safe to assume
they won't want it focused if they return to it.
This prevents that happening.
This adds a data-attribute flag to allow this
behaviour to be overridden.
We have some situations where the assumption here
isn't appropriate, for example on pages where the
component with autofocus is in a sticky element.
This means it will appear offscreen when the page
loads but, when its parent becomes sticky, will be
visible again.
We keep getting people requesting branding when they already have the
branding they want set. Seems like they don’t realise we’re doing it
automatically. This might help.
The delete link was inheriting 1px of extra top padding meant to align
it when displayed alongside a button. In this case it’s not being
displayed alongside a button, so doesn’t need the extra padding.
Since we're calling `User.has_template_folder_permission` directly
in a few places (notably the `folder_path` template macro), we need
to check that the service has the feature flag enabled first. This is
usually done by the caller, but template macro doesn't have access to
`current_service`. To avoid passing it in each time the macro is called
we're adding a temporary check inside the method itself.
This commit can be reverted completely when we remove the service
feature flag.
