Suggestion: Support all extended ASCII and/or UTF-8 characters in requirement keys

Fix versions

Priority

Description

Special chars now work inside properties, but sadly not for context menus: When selecting a word with a special char (e.g. a german umlaut) the tooltip popup doesn't contain the RYogi icon to create an object. Selecting words in the same line/text without special chars shows up the RYogi icon inside the tooltip popup.

So we still aren't able fill our dictionaries with german or french words containing special chars. Inserting such words as glossary items is still only possible ba manually adding a RYogy macro to the text, which is very elaborate.

Edit by Requirement Yogi

  • Already present: A-Z a-z 0-9 - . _

  • Requested by the customer: § (often needed by our justice customers), é, á, ß, ä, ö, ü, /, &

  • Note that the Unicode BMP includes surrogates and characters that look like the latin alphabet, which are sometimes criticized as a way for pirates to mislead users. However, requirement keys don't seem like an attack vector.

Actual implementation

  • Supported: All characters in the Unicode BMP including space and é, á, ß, ä, ö, ü and &.

  • Unsupported:

    • / and \ (Sorry, but they are routinely erroneously decoded by various HTTP services),

    • Ascii control characters 0-31, DEL (127 \u007F), Unicode control characters (\uFFEF and above) and non-BMP unicode characters (secondary and ternary plane).

    • Inline-replacements work in the same page, but don't work if you want all pages in the space to be replaced, when there are whitespaces and special characters in the text.

  • This is an alpha release:

    • Do NOT use extended characters on production. "A-Z a-z 0-9 _ . -" are OK.

    • We may change the storage format for the requirement macro, so existing macros with strange characters may become unreadable.

  • Points of interest:

    • Inline replacement of requirement keys (implemented in 2.5.5, but without the spaces),

    • Refreezing baselines with extended keys (implemented in 2.5.5),

    • Renaming requirements with extended keys (implemented in 2.5.5),

    • UPPERCASE(ü) isn't equal to Ü for the default Postgresql collation, so we won't support collisions between the two. In otherwords, it will be possible to create both keys Aü-001 and AÜ-001 for those who activate UTF-8 keys.

  • How to activate: See below.

Examples

How to activate

Please remember that although we are more confident now, it hasn't been tested by many people yet. You may have to reindex some requirements, lose their history or lose some links to Jira if we have done something very wrong, and you will have to accept the cost of this. We recommend testing on a staging database. To activate, use RY 2.5.5 and activate the system property -Drequirementyogi.extendedkeys=true (usually in the set-env.sh startup script).

Attachments

3

Activity

Show:

Adrien RagotJanuary 25, 2022 at 6:29 PM

No feedback from any customer for more than 3 months after release, therefore we assume it is polished enough to close the ticket. Please open new tickets if you find problems related to UTF-8 keys in less visible parts of the product.

Thank you all for pushing us to release this feature!

Adrien RagotOctober 11, 2021 at 2:39 PM

Hi Christian,

In RY-834 , we have made this feature standard, and published it in Requirement Yogi 3.0 this morning. It is now possible to define almost anything as a requirement key, except “/” and “\”.

Best regards,

Adrien Ragot

Christian DähnMarch 23, 2021 at 5:10 AM

My last experience was, that we found the above mentioned two bugs, which prevented the usage in production environment (especially the bug with broken links zu requirements with special chars).

Currently I let my colleagues run the test again with the current Confluence & RYogy version and then publish the results here again.

Cloud:
We are working for the German government and thus won’t go into the cloud for data privacy and legal regulation reasons. We and many other customers cannot understand the argumentation of cloud-first as “no problem” and “anyone can trust us” even with Privacy Shield beeing stated as illegal for all European countries. So we will migrate to Datacenter and hope, that this last on premise product will live longer - otherwise we have to leave the Atlassian world and migrate back to Microsoft or others.

Adrien RagotFebruary 24, 2021 at 4:07 PM

Hi Alexander,

For the moment, the state of this feature is:

  • We haven't had many bug reports from Christian and yourself, therefore I am not confident to completely go public with the special characters,

  • We have only 2 customers (Christian and yourself) with this request, so it will probably remain a case-by-case feature, only for the two of you.

Concerning your choice between alternatives vs us, I highly recommend that you use alternatives suited for glossaries. We design our plugin for requirements, which have a different set of needs from a dictionnary, for example all the links are visible in the popup, and we will never be completely matching your expectations. Therefore it is always better to use a product designed for the usecase you have.

Best regards,
Adrien Ragot

Alexander PoryvkinFebruary 8, 2021 at 1:01 AM

@adrien, can you please refresh the state for this feature?

Resolved

Details

Assignee

Reporter

Sprint

Labels

Participants

Chris Mitchell

Components

Affects versions

Requirement Yogi

Created February 24, 2020 at 12:22 PM
Updated January 25, 2022 at 7:24 PM
Resolved January 25, 2022 at 6:29 PM