Describe the bug
Kitodo does not explicitly save negative or "false" values for boolean metadata to the meta.xml file of a process, but instead skips saving the metadata at all for values interpreted as false. I think this is meant to simplify the handling of boolean metadata. Unfortunately, this does produce some problems with boolean metadata and the configuration of rulesets. One such problem is that any preset for a boolean metadata in the ruleset is interpreted as true:
https://github.com/kitodo/kitodo-production/blob/836739862427bc69f8631d2d2cf87697c0891aa2/Kitodo-API/src/main/java/org/kitodo/api/dataeditor/rulesetmanagement/SimpleMetadataViewInterface.java#LL49C1-L51C6
So getBooleanDefaultValue actually just returns whether a preset is configured at all, not it's actual value.
The constructor of a boolean metadata uses this method to determine the value of the metadata if no value for this metadata was found in a processes meta.xml file:
https://github.com/kitodo/kitodo-production/blob/836739862427bc69f8631d2d2cf87697c0891aa2/Kitodo/src/main/java/org/kitodo/production/forms/createprocess/ProcessBooleanMetadata.java#LL50C3-L50C3
Since false boolean values are not saved to the meta.xml, this construction of a boolean metadata with value false when opening a process in the metadata editor falls back on the default values/presets defined in the ruleset in the lines quoted above. This leads to checkboxes for explicitely deactived metadata to always be checked again when opening a corresponding process in the metadata editor again.
To Reproduce
Steps to reproduce the behavior:
- Configure a boolean metadata in the ruleset with a non-empty preset, for example
<key id="accessRestriction">
<label>Zugriffsbeschränkung</label>
<label lang="de">Zugriffsbeschränkung</label>
<label lang="en">Access restriction</label>
<codomain type="boolean"/>
<option value="yes"/>
<option value="no"/>
<preset>no</preset>
</key>
- Add a metadata of this type to a process in the metadata editor
- Deactivate the metadata, e.g. remove the check from the checkbox
- Save the process
- Re-open the process in the editor
- Observe that check has been re-applied
Expected behavior
Boolean metadata that has been explicitely saved as false e.g. "unchecked" should not be overwritten by potential presets in the ruleset.
Release
3.6.0-SNAPSHOT and prior
Describe the bug
Kitodo does not explicitly save negative or "false" values for boolean metadata to the
meta.xmlfile of a process, but instead skips saving the metadata at all for values interpreted asfalse. I think this is meant to simplify the handling of boolean metadata. Unfortunately, this does produce some problems with boolean metadata and the configuration of rulesets. One such problem is that any preset for a boolean metadata in the ruleset is interpreted astrue:https://github.com/kitodo/kitodo-production/blob/836739862427bc69f8631d2d2cf87697c0891aa2/Kitodo-API/src/main/java/org/kitodo/api/dataeditor/rulesetmanagement/SimpleMetadataViewInterface.java#LL49C1-L51C6
So
getBooleanDefaultValueactually just returns whether a preset is configured at all, not it's actual value.The constructor of a boolean metadata uses this method to determine the value of the metadata if no value for this metadata was found in a processes
meta.xmlfile:https://github.com/kitodo/kitodo-production/blob/836739862427bc69f8631d2d2cf87697c0891aa2/Kitodo/src/main/java/org/kitodo/production/forms/createprocess/ProcessBooleanMetadata.java#LL50C3-L50C3
Since false boolean values are not saved to the
meta.xml, this construction of a boolean metadata with valuefalsewhen opening a process in the metadata editor falls back on the default values/presets defined in the ruleset in the lines quoted above. This leads to checkboxes for explicitely deactived metadata to always be checked again when opening a corresponding process in the metadata editor again.To Reproduce
Steps to reproduce the behavior:
Expected behavior
Boolean metadata that has been explicitely saved as
falsee.g. "unchecked" should not be overwritten by potential presets in the ruleset.Release
3.6.0-SNAPSHOT and prior