[Instruments] Escaping issue optimal - Only HTML escape on data retrieval

[ridz1208]

Brief summary of changes

This PR fixes the escaping issue that occurs when a text field in an instrument contains an HTML special character. The solution employed here is to avoid HTML escaping special characters before database save and to instead escape them on form load (in the display logic).

Cons:

• This solution is major and might have wider effects that predicted on any other form in loris still using lorisforms

Pros:

• optimal permanent solution, not a temporary hack
• Collateral advantage of preventing scripting in filter fields

Modules using LorisForm affected by changes (other than instruments):

• examiners
• help_editor
• my_preferences
• user_accounts
• ...

Modules NOT using LorisForm (directly loading data) affected by changes: (added to https://github.com/aces/Loris/projects/27)

• configuration
• publication
  • This will need it's own ticket. Files allow some special characters that it shouldn't. some fields get HTML char decoded, some dont.
• acknowledgements
• bvl_feedback
• candidate_parameters
• data_release
• document_repository
• electrophysiology_browser
• genomic_browser
• issue_tracker
• media (edit function only)

Modules NOT loading any data on forms (LorisForm or otherwise)

• survey_accounts
• imaging_uploader
  • Does not seem to allow special characters by constantly validating matches with PSCID,DCCID and visitlabel; no free text allowed

Found using search on

• createText
• addBasicText
• addBasicTextArea
• addTextAreaGroup (unused)
• createTextArea (unused)
• addTextAreaGroup (unused)
• createDate (unnecessary)
• addDate (unnecessary)
• createStatic (unnecessary)
• addStatic (unnecessary)
• createTime (unnecessary/unused)
• addTime (unnecessary/unused)
• year (unnecessary/unused)
• file (unnecessary/unused)
• checkbox (unnecessary/unused)

Alternate to: #7776
Fixes #7489
Replaces #7490

Testing instructions (if applicable)

1. Go to an instrument with text element fields (not including text area element since the issue did not apply to those elements)
2. Outside of this PR, attempt to save a value in the text element that has quotations in it.
3. Notice that it does not display properly after clicking "save"
4. check out this PR
5. Attempt again to save a value with quotations in it

Make sure to test other usecases as well

1. behaviour when the form contains an error (triggering a reload with erroneous fields highlighted)
2. behaviour when there are multiple ",<,> or & in the string
3. behaviour when the instrument status sidebar is modified (is it affected by the reload)

Review:

• Make sure all field types that should be escaped are escaped (select fields?)

Link(s) to related issue(s)

• Resolves # (Reference the issue this fixes, if any.)

[ridz1208]

Updating this tool cause it still might be used in this release by some projects and it was broken

[ridz1208]

closing for now. will require a substantial amount of work

[ridz1208]

@driusan I dont' know if there is a need for a script to remove already encoded data (it seems unlikely that any already exist outside of instruments)

so technically this is ready for review

[ridz1208]

I just dont think this is gonna happen and no issues have recently poped up about it.