-
Notifications
You must be signed in to change notification settings - Fork 3
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
UIQM-697: Field 008: Validate the length of subfields. Add backslashes if the length of a subfield of field 008 is shorter, if longer - cut off the extra characters. #727
Conversation
…s if the length of a subfield of field 008 is shorter, if longer - cut off the extra characters.
const runBackEndValidation = useCallback(async (marcRecords) => { | ||
// if the length of a subfield of field 008 is shorter, then add backslashes, | ||
// if longer, then cut off the extra characters. | ||
const fillIn008FieldBlanks = useCallback((marcRecords) => { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Let's move this out to prepareForSubmit
in Edit/Create/Derive wrappers. This hook should assume that the provided data is what is going to be sent to BE to save, so it should validate this data without changes
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This needs to be done only for BE validation. marcRecords
for BE should contain the correct length of field 008 subfields to avoid 400 error, but FE shouldn't, in order to catch errors and display inline messages.
If we put this functionality in prepareForSubmit
for BE and FE, we will get the correct length of subfields and will not see inline errors.
Quality Gate passedIssues Measures |
Purpose
Approach
Issues
UIQM-697
Screencast
2024-09-17_14h55_53.mp4
TODOS and Open Questions
Learning
Pre-Merge Checklist
Before merging this PR, please go through the following list and take appropriate actions.
If there are breaking changes, please STOP and consider the following:
Ideally all of the PRs involved in breaking changes would be merged in the same day to avoid breaking the folio-testing environment. Communication is paramount if that is to be achieved, especially as the number of intermodule and inter-team dependencies increase.
While it's helpful for reviewers to help identify potential problems, ensuring that it's safe to merge is ultimately the responsibility of the PR assignee.