F hide properties
Summary
For https://gitlab.indiscale.com/caosdb/customers/leibniz-zmt/management/-/issues/130. Allows to hide properties for certain users/roles.
Focus
A few new HTML classes have been introduced to hide/show properties and allow for changing css styling depending on properties being hidden or not.
Please check carefully:
- Is the new default "Properties are hidden initially, unhidden afterwards" working properly and the desired outcome?
- Do you see more elegant ways of obtaining the same behavior?
Test Environment
Start a caosdb-server and caosdb-webui with a valid ext_prop_display.json
config file and BUILD_MODULE_EXT_PROPERTY_DISPLAY=ENABLED
.
For example, use the LinkAhead demo profile in this branch, add BUILD_MODULE_EXT_PROPERTY_DISPLAY=ENABLED
to profiles/demo/custom/caosdb-server/caosdb-webui/build.properties.d/99.demo.conf
and add the following contents in a profiles/demo/custom/caosdb-server/caosdb-webui/conf/ext/json/ext_prop_display.json
:
{
"MusicalInstrument": {
"hide": [
{"name": "price", "roles": ["anonymous"], "users": []},
{"name": "Manufacturer", "roles": [], "users": ["admin"]}
]
}
}
(feel free to add to and change the config).
Verify that
-
price
is hidden fromMusicalInstrument
s for anonymous -
Manufacturer
is hidden for admin - the edit mode still works properly even for entities with hidden properties: They are shown while editing, they are correctly updated/inserted, and they are correctly hidden/shown after editing.
Then, check that for BUILD_MODULE_EXT_PROPERTY_DISPLAY=DISABLED
or after deleting profiles/demo/custom/caosdb-server/caosdb-webui/conf/ext/json/ext_prop_display.json
, all properties are shown. In a LinkAhead test setting, also verify that for BUILD_MODULE_EXT_PROPERTY_DISPLAY=DISABLED
, the alternating property backgrounds are recovered (see https://gitlab.indiscale.com/caosdb/src/theme-linkahead/-/merge_requests/3/diffs).
Please also check the new documentation and unit tests.
Check List for the Author
Please, prepare your MR for a review. Be sure to write a summary and a focus and create gitlab comments for the reviewer. They should guide the reviewer through the changes, explain your changes and also point out open questions. For further good practices have a look at our review guidelines
-
All automated tests pass -
Reference related issues -
Up-to-date CHANGELOG.md (or not necessary) -
Annotations in code (Gitlab comments) - Intent of new code
- Problems with old code
- Why this implementation?
Check List for the Reviewer
-
I understand the intent of this MR -
All automated tests pass -
Up-to-date CHANGELOG.md (or not necessary) -
The test environment setup works and the intended behavior is reproducible in the test environment -
In-code documentation and comments are up-to-date. -
Check: Are there specifications? Are they satisfied?
For further good practices have a look at our review guidelines.