Fix for issue preventing validation of url with only whitespace

[CWDamm-Kint]

Types of changes

• Bugfix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to not work as expected)

Description of Change

Previously, the clean function was assigning tile.data[nodeid] as None if the url provided was entirely whitespace, which prevented it from being validated. This then prevented further data entry after saving.

The clean function now separates out some of the logic, so that the url_label is replaced with None if blank or whitespace, but the full tile.data[nodeid] is only assigned as None if both values are falsey. This means that blank but non-empty url strings still go through to validation.

Issues Solved

Closes #10796

Checklist

• I targeted one of these branches:
  • dev/8.0.x (under development): features, bugfixes not covered below
  • dev/7.6.x (main support): regressions, crashing bugs, security issues, major bugs in new features
  • dev/6.2.x (extended support): major security issues, data loss issues
• I added a changelog in arches/releases
• I submitted a PR to arches-docs (if appropriate)
• Unit tests pass locally with my changes
• I added tests that prove my fix is effective or that my feature works
• My test fails on the target branch

Accessibility Checklist

Developer Guide

Topic	Changed	Retested
Color contrast
Form fields
Headings
Links
Keyboard
Responsive Design
HTML validation
Screen reader

Ticket Background

• Sponsored by: Knowledge Integration
• Found by: @SDScandrettKint
• Tested by: @CWDamm-Kint
• Designed by: @CWDamm-Kint

Further comments

[SDScandrettKint]

This has been targeted at 7.6.x (rather than 8.0.x) because it was recently raised from an AfHER context, causing a semi-data loss state, as the entire tile needs to be deleted in order to update a URL. If the nodegroup held a small set of nodes then it wouldn't be as major, but due to the number of nodes in some of the AfHER nodegroups (e.g. External Cross References, or some Monument/Area Phases) it means that a lot of data must be deleted and re-inputted.

Since AfHER will be on 7.6.x soon (and for a long period of time), it'd be great to get semi-data loss scenarios like this into 7.6.
Interested in others thoughts!

[SDScandrettKint]

I've noticed that this fix doesn't set the node value to null if there is no data, instead it looks as such:

{
  "5ed66e9e-b71a-11ef-a84a-00155dbda2ca": {
    "url": "",
    "url_label": null
  }
}

We need to the data to appear as null in the backend, but still editable in the front end.

This issue is related to this recent string issue #11658 as they both concern the back-end having a null value but the front-end either not reflecting this.

[chiatt]

I just tried to reproduce the bug that this ticket addresses #10796, but I couldn't reproduce the issue given the instructions in the ticket. It seems like it addresses a different problem. Maybe a different issue is needed?

[SDScandrettKint]

I just tried to reproduce the bug that this ticket addresses #10796, but I couldn't reproduce the issue given the instructions in the ticket. It seems like it addresses a different problem. Maybe a different issue is needed?

I can reproduce it in 7.6, but only with a newly created URL. Once I refresh the page and try to edit it further times the issue doesn't occur (shown below).

URL_saving_issue_76.mp4

The second input that doesn't trigger a dirty state will have it's value persist in the node preview, while being constantly removed from the input box (this is after going to and from different nodegroups)

It's odd how this issue occurs after the inital saving of the value when it is null, but after refreshing the page data can be added and reverted to null with no problems.