| Summary: | Hardcoded values in subfield constraint visibility | ||
|---|---|---|---|
| Product: | Koha | Reporter: | paxed <pasi.kallinen> | 
| Component: | Templates | Assignee: | Owen Leonard <oleonard> | 
| Status: | NEW --- | QA Contact: | Testopia <testopia> | 
| Severity: | enhancement | ||
| Priority: | P5 - low | CC: | josef.moravec | 
| Version: | unspecified | ||
| Hardware: | All | ||
| OS: | All | ||
| GIT URL: | Initiative type: | --- | |
| Sponsorship status: | --- | Crowdfunding goal: | 0 | 
| Patch complexity: | --- | Documentation contact: | |
| Documentation submission: | Text to go in the release notes: | ||
| Version(s) released in: | Circulation function: | ||
I am not sure about this one - what would be the advantage of moving them into the db? The 3 checkboxes GUI seems like the easiest way to translate this to the user. For people working with SQL we keep some documentation here: https://wiki.koha-community.org/wiki/Hidden_values  | 
The MARC subfield constraint editor shows checkboxes for the subfield visibility (OPAC, Intranet, Editor, Collapsed, Flagged). The state of these checkboxes is encoded in the database as a single integer, and the conversion is done in marc_subfields_structure.js via hardcoded magic values: if ( flagged_checked ) { hidden_value='-8'; } else if ( opac_checked && ! intranet_checked && ! editor_checked && collapsed_checked ) { hidden_value='-7'; } else if ( opac_checked && intranet_checked && ! editor_checked && ! collapsed_checked) { hidden_value='-6'; etc. These should be moved into the database, perhaps as authorised values.