Skip to content

F hide properties

Florian Spreckelsen requested to merge f-hide-properties into dev

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:

  1. Is the new default "Properties are hidden initially, unhidden afterwards" working properly and the desired outcome?
  2. 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

  1. price is hidden from MusicalInstruments for anonymous
  2. Manufacturer is hidden for admin
  3. 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.

Edited by Timm Fitschen

Merge request reports