Repository navigation
Customisable error messages - #299
Merged
Merged
Conversation
Rather than generate the error message in the backend, we know generate an error structure instead which can be used to generate error messages. This functionality should live in the core dudk code, but be separate from the general backend functionality as it is very front-end specific and will be configured from a client.
These messages will be provided as a JSON object, containing the error variants as keys and the messages to be interpolated as values.
rossjones
changed the title
rossjones
marked this pull request as ready for review
August 29, 2025 13:57
simonwo
approved these changes
Aug 29, 2025
| <h2 class="govuk-heading-m validation-error-message">{{warning.message}}</h2> | ||
| <p class="govuk-body">This warning occurs {{warning.meta.count | count_string}} in your data. The first time at row {{ warning.meta.first}}:</p> | ||
| <h2 class="govuk-heading-m validation-error-message"> | ||
| {% switch warning.variant %} |
Member
There was a problem hiding this comment.
Does it make sense to DRY this into a macro? Just one that is inline on this template? Whilst I don't think most people would naturally write macros, I guess they might recognise that changing the content in one will have the desired effect? Idk.
Contributor
Author
There was a problem hiding this comment.
I think it'll be easier/better once we're not duplicating errors in warnings etc but will need to figure out which is which. I'll do that in this PR as I've found another error I'd missed anyway.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Error messages are currently generated by the backend validation functions, but are not able to be customised by our users.
This PR now returns error objects back to the client (prototype kit templates) so that they can choose what the error messages should contain if the language used by default is not suitable. These errors look like:
These properties for each error can be used in the templates, but the value field is not useful here as the errors are grouped by 'variant' and 'field' so that they appear together.
Currently it requires users to update both the error messages and the warning messages until we have more clarity on which 'errors' are in each category. It is possible to use the error 'variant' (type of error), the 'type' code (the expected type of that field) and the 'field' name in error messages, but the 'value' field is the value where the error was found, and this is not useful when errors are grouped together.
In future, we may with to move the error message customisation into the dudk itself so that it can be used by non-prototype kit users, and to re-instate backend support for customisable error messages, you can revert the commits 966afd6 and ee6f49d