New node's text does not match entered text

[younrx]

I went through a wierd behavior when creating a new comment/note.

First, the tag [TODO] is automatically added (I am not sure that this was the whished behavior, since there is a button Mark as To-Do to add this tag). Second, if I create a note with one or various strings into square brackets, they are all removed (except for tag strings directly preceded by another tag string).
Here are a few examples:

n°	Text entered in new note	Text obtained after creating note
1	text	[TODO] text (tag TODO added automatically)
2	[tag1]	[TODO] [tag1]
3	text [tag1]	[TODO] text [tag1]
4	[tag1] text	[TODO] text
5	[tag1] [tag2] text	[TODO] text
6	[tag1] text [tag2]	[TODO] text [tag2]
7	[tag1] text [tag2] [tag3]	[TODO] [tag3]
8	[tag1] text [tag2][tag3]	[TODO] text [tag2][tag3]
9	[tag1] text [tag2] [tag3] [tag4]	[TODO] [tag4]
10	[tag1] text1 [tag2] [tag3] text2 [tag4]	[TODO] text2 [tag4]
11	[tag1] text1 [tag2] [tag3] text2 [tag4] [tag5]	[TODO] [tag5]
12	[tag1] text1 [tag2] [tag3] text2 [tag4][tag5]	[TODO] text2 [tag4][tag5]

It is possible to have the note obtained text equal to the entered text by doing note>edit>cancel. The displayed text is then updated and has the correct value. Doing a note>edit>save before seems to make the "reverse" behavior impossible. It seems to be due to another mechanism, thus I have submitted another issue for this: #10

Additional note: This behavior not only happens when creating a note, but also when using the Mark as XXX feature. Using this feature sometimes even removes more text. For example, string text [tag2] [tag3] is displayed as [TODO] text [tag2] [tag3] on note creation (this is equivalent to the third line in the table above) but it is displayed as [XXX] [tag3] after using Mark as XXX.

[ggabarrin]

Hey @younrx, thanks for reporting this issue and for providing these thorough details :) We were able to reproduce it and identify the root cause.

Updating the note status was misbehaving because of the way we were removing the previous status. We were replacing any matches with the ^\[.*\] regex with an empty string (''), which explained all the examples you provided.

We'll be releasing a fix shortly.

Thanks again!

[younrx]

Alright I understand it better now ^^
For a more acurate behavior, you can use the ? quantifier to match as few characters as possible. The regex ^\[.*?\] gives you the desired output (note that I have also removed the final space character, to fix the behavior underlined lines 8 and 12 of the table above).

But I would recommend to be more precise and replace the string really corresponding to one of your tags by the new tag, instead of replacing a string corresponding to a tag pattern by an empty string and then adding a new tag. In this way, any tag added by a user would be preserved.
To achieve this you can use the following regex: \[(TODO|Vulnerable|Not Vulnerable)\]. It will only match the strings [TODO], [Vulnerable] and [Not Vulnerable]. Starting the regex with ^ will return matches only when these strings are in the beginning of the analyzed text. If you get rid of the char ^ in the regex, you will have matches no matter where the strings are in the analyzed text (in this way it will work even if a user adds text before the tag in the note comment, for instance).

[ggabarrin]

Hey @younrx, thanks for your suggestion! :)

We ended up removing the regex altogether. Instead of hard-coding all the current status options (TODO, Vulnerable and Not Vulnerable), we are now iterating through all possible values for the NoteStatus with a forEach function, just in case we add any new status options in the future.

This issue should be fixed by PR #11.

Thanks again!

[younrx]

Cool! That's a better strategy yep!