Makes it inherit from GovukTextInputField.
Changes to govuk_field_widget to allow the value
attribute to be set by passing a value keyword
argument to the __call__ method.
Includes changes to templates that use this form
and associated tests.
We had two identical callback form classes. One for delivery callbacks
and one for inbound sms callbacks. Since they did not differ I consolidated
them into one CallbackForm class that they both inherited from previously.
I also substituted field classes for this form with new fields
that cooperate with gov uk frontend.
ListEntry component uses FieldList field to group
textboxes. Textboxes can be text inputs, email fields
or international phone number fields. This converts
all field-lists to use:
- GovukTextInputField
- GovukEmailField
- InternationalPhoneNumber
Affects these forms:
- OrganisationDomainsForm
- GuestList
Also changes to related Javascript:
Update list-entry JS tests to match new HTML
Updates the HTML the JS operates on in the test
(a fixture representing the HTML in the page on
load) to match the new GOVUK Frontend we are
generating.
Make list-entry JS work with GOVUK Frontend HTML
The existing list-entry JS did a few things that
clashed with how the new HTML works:
- added a 'input-' prefix to the id attributes
of all text-inputs
- did not make its name and id attributes values
match
The new HTML has id and name attributes that
match so these changes remove the prefix for id
attributes and makes them match the name
attribute.
To understand these changes, it is useful to
know how the values for id and name attributes are
generated:
1. the id attribute for the component element is
stored
2. the 'list-entry-' prefix is removed and the
remainder is used to generate ids
For example, if the component's id is
'list-entry-domains', the id will be 'domains-1',
where the text-input is the first one.
This also adds some logic to the HoganJS template
to make the value attribute optional, so it is
only added if it has a non-null value. This
matches the behaviour of the text-input component
used in the new list-entry component.
Also change whitelist references to guestlist in tests
- we forgot to do it earlier, when we moved from calling this
feature whitelist to calling it guestlist.
Changes its:
- StringFields to GovukTextInputFields
- EmailFields to GovukEmailFields
Includes changes to templates that use this form
and associated tests.
Updates StringField to GovukTextInputField.
These changes also affect the following forms that
inherit from BaseTemplateForm:
- SMSTemplateForm
- EmailTemplateForm
Includes changes to templates that use these forms
and associated tests.
Changes those fields in the following forms:
- SearchByNameForm
- SearchUsersByEmailForm
- SearchUsersForm
- SearchNotificationsForm
Includes changes to templates that use this form
and associated tests.
Changes those classes so they have the same
interface as a GOVUK field when instantiated and
render GovukTextInputField HTML.
Includes changes to templates that use this form
and associated tests.
Changes those fields (and sometimes also regular text input fields)
in the following forms:
- LoginForm
- RegisterUserForm
- ChangeEmailForm
- FeedbackOrProblem
- AcceptAgreementForm
- ChangeNameForm (only name field here, but used in the same template
field as ChangeEmailForm here: app/templates/views/user-profile/change.html)
Also includes changes to templates that use this form
and associated tests.
Converts them directly in the following forms:
- LoginForm
- ConfirmPasswordForm
Changes the password function to return
GovukPasswordField instead of PasswordField which
effects the following forms:
- RegisterUserForm
- RegisterUserFromInviteForm
- RegisterUserFromOrgInviteForm
- NewPasswordForm
- ChangePasswordForm
It also updates StringField on RegisterUserFromOrgInviteForm
to GovukTextInputField
Also includes changes to templates that use this
form and associated tests.
At the moment viewing a broadcast is limited to those users who have
the `send_messages` permission.
This doesn’t match how we describe the permissions on the team members
page
This commit makes it so that any team member can see a broadcast that’s
in any state other than `draft`.
If a library has groups, we should show a link instead of selecting the
group directly.
Then we can give the user the choice of selecting the whole of that
group, or specific areas within the group.
For now the only libraries we have with groups are local authorities,
which group electoral wards.
Password managers will try to guess what they should save as a username
by looking at the fields on the page where you set up your password.
When registering from an invite the email address (what we use as a
username) is predefined, and only shown on the page as text, not an
input.
This commit also adds a hidden input field for password managers to pick
up.
Adapted from: https://github.com/UKGovernmentBEIS/beis-opss-psd/blob/master/app/views/users/complete_registration.html.erb#L29-L36
At the moment they will get a ‘technical difficulties’ error if they
try.
We probably want to do something around letting people self-approve
broadcasts in trial mode, but for now just telling them they can’t is a
better experience than ‘technical difficulties’ (and will probably be
close to what they should see on a live service as well).
`EmailPreviewTemplate.subject` returns a string of HTML, with any
user-submitted HTML already escaped:
b5a61bfb7b/notifications_utils/template.py (L672)
What won’t be escaped is the HTML needed to redact the placeholders. We
generate this HTML so we know its safe, and doesn’t need to be escaped.
However when we pass it to Jinja, Jinja doesn’t know this, so will try
to escape it. This means users will see the raw HTML.
We can get around this by using Flask’s `Markup` class to tell Jinja
that the string is already sanitised and doesn’t need escaping again.
Text message templates don’t have this problem because they already
return `Markup`: b5a61bfb7b/notifications_utils/template.py (L288)
Letter templates don’t suffer from this problem (because they don’t
support redaction) but without making the same change they would still
double-escape ampersands, greater-than symbols, and so on.
Once you’ve created a broadcast you’re taken back to the dashboard. This
feels too passive, and you might miss that the broadcast still needs
approval.
We should be much more explicit that you now need to find someone to
approve your broadcast. Taking someone directly to the page for a
broadcast lets us give more information about the status of the
broadcast and what the next steps should be.
This is an initial, prototype-quality attempt at introducing some kind
of tour for users new to broadcasting. A lot of the users we’re speaking
to don’t have a good concept of what broadcasting means, which is
causing usability problems down the line.
We did a similar thing in the early days of Notify to explain the
concept of message templates and personalisation.
