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

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).