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.
Supported: All characters in the Unicode BMP including space and é, á, ß, ä, ö, ü and &.
/ 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.
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).
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.
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.
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.
@adrien, can you please refresh the state for this feature?
As for the journey to Cloud, we will be on server i guess for at least 2 years. And then, probably go to the data-center version. And i think many of us will do the same. So the current plugin is worth to develop.
When are you going to publish this feature with the supported symbols?
Hi, Adrien! I have tried some term plugins that are presented in the marketplace right now and they are able to highlight somehow terms with special symbols and spaces. (Spectrum glossary and Advanced Terms). Also, the inline feature also works with them. Unfortunately, they are not able to generate any list of terms based on the pages where the terms were mentioned.
We have seen the news. Currently, I have no idea which way our company will choose either migration to the Cloud or go to the Data-Center version..