A few of note
Count in list of live services - this should be set to no in the API (to
be implemented) so we never show broadcast services in the list of live
services to reduce security leaks
Organisation - all broadcast services are currently going to be found in
a single organisation so we keep track of them easily. Therefore there
is no need to allow the changing of the organisation
Email authentication - we may in time not allow these services to use
email auth to log in but this hasn't been decided so let's keep it for
the moment
Rate limit - although a service may end up using our API to create
broadcasts, there is currently no rate limit check on this endpoint
and it's also extremely unlikely that any service would ever breach
the default limit
This stops the 'inset text' linking to the design system on the
'edit-and-format-messages' page. The link has been removed to avoid
confusion - someone thought they needed to use the design system
code in order to create inset text in templates.
Add more spacing between characters for billing reference number and PO number, so they are easier to read.
Also remove unnecessary autofocus.
Co-authored-by: Chris Hill-Scott <me@quis.cc>
As per ticket and as per Caley's request, so everything can be
edited together.
Also pluralise labels for billing contact info, to indicate
that putting multiple in is ok, and widen the input fields so
that it is more comfortable to input multiple contact details.
Broadcasts created by the API are different in that:
- they aren’t created by any user, so don’t have a `created_by_id`
- they are created instantly, not in steps, so don’t have an
`updated_at` time
This commit alters the views to account for when these pieces of
information aren’t present.
The following were added without the macro ever
being called:
- app/templates/views/add-service-local.html
(added in
e6f49825e5)
- app/templates/views/service-settings/data-retention/edit.html
(added in
4b8b571a87)
- app/templates/views/organisations/organisation/settings/edit-domains.html
(added in
936883bf7b)
The following were used when they were first added
but not removed when the macro stopped being used:
- app/templates/views/edit-letter-template.html
(macro removed in
20ae200de9)
- app/templates/views/organisations/organisation/settings/edit-agreement.html
(macro removed in
45526598c6)
Includes changing the code so that the radios
aren't split into two columns in the HTML present
when the page loads. This layout is now added by
the JS.
The last_dest_idx variable should always have been
tracking the last index in the source list. The
original intention, implemented incorrectly, was
to just append any items which source has no item
at that index.
Update all methods that were previous calling @cache.delete('service-{service-id}-template-None') to instead call _delete_template_cache_for_service
Remove call to get service templates, it's not needed since all template version cache is being deleted.
If a user has only send_message permissions, when they click on a
template name they are currently taken to the `send_one_off` page. This
is incorrect as if there is more than one SMS sender or email reply to
address, then they should pick the address they wish to use.
This commit fixes that bug by redirecting them to the `set_sender`
route. Note, if there is only one sender then the `set_sender` will
redirect the user on to the `send_one_off` route.
https://www.pivotaltracker.com/story/show/176541486
A comment on the pull request for this branch
pointed out that it's not clear why the 'items'
list is deleted and then reassigned in
extend_params:
https://github.com/alphagov/notifications-admin/pull/3770#pullrequestreview-573067465
The simple reason is that we want to use
merge_jsonlike to merge params and
param_extensions (passed in as extensions) but
merge_jsonlike doesn't merge lists correctly.
I realised that if we just make merge_jsonlike
merge lists correctly, we can use it for
everything extend_params does.
This commit does that, and replaces all calls to
extend_params with merge_jsonlike.
Because extend_params is used across many form
field classes, and so many pages, I took the
following precautions after making those changes:
1. found every use of param_extensions
2. looked at the merges onto params that each would
cause and deduped them to a final list of 6(!)
3. tested pages containing fields from that list
4. added new testcases to the merge_jsonlike tests
for any merges that exist in our codebase but
not in our tests
