Skip to content

F long text properties

Timm Fitschen requested to merge f-long-text-properties into dev

Summary

Implements https://gitlab.com/caosdb/caosdb-webui/-/issues/202

Related: https://gitlab.indiscale.com/caosdb/customers/leibniz-zmt/management/-/issues/79

Two new build variables BUILD_LONG_TEXT_PROPERTY_THRESHOLD_SINGLE and BUILD_LONG_TEXT_PROPERTY_THRESHOLD_LIST.

Any numeric value>0 will cause text properties with values longer than the threshold to be put into a details tag with a shortened summary. DISABLED will disable this feature. Defaults: 140 characters for single values, 40 for list values.

Focus

Magic happens in xslt. This way it does not collide with the edit mode or the ext_cosmetics module because the actual text value is stored with the correct css class name (caosdb-f-property-raw-value) inside the details tag. The summary is being transformed by the ext_cosmetics module (linkyfy) and it is being ignored by the edit mode.

Styling is css-bases of course.

Test Environment

There is a simple test for the xslt script. The styling should be tested manually tho

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)
  • Up-to-date JSON schema (or not necessary)
  • Appropriate user and developer documentation (or not necessary)
    • How do I use the software? Assume "stupid" users.
    • How do I develop or debug the software? Assume novice developers.
  • 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)
  • Appropriate user and developer documentation (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 Florian Spreckelsen

Merge request reports