Formatting changes to rich text fields (such as bold or italic) should not trigger a suspect link. A lot of time is being wasted examining suspect links which are the results of these non-meaningful changes.
By looking at the Idea it seems like you are suggesting that formatting changes should be ignored as trivial and not considered as changes significant enough for raising flags. This could be tricky as the field where the rich text changes are being made is configured by the administrator as a significant edit field - right?
Also, the formatting information can contain semantic information, e.g. strikethrough. When requirements are rich-text, there is no way of telling if a formatting change is changing the meaning of a requirement or not.
Yes Roman you are correct. This is going to be a big challenge if we have to try and solve this use case because unlike the rest of the formatting (correct me), a strikethrough can change the entire meaning of a Requirement. I don't think there is another feature like strikethrough within rich text formatting that can change meaning!
Well, red/green markup or any kind of colouring, even changing from an unordered list (meaning a set) to an ordered list (meaning a sequence) could also alter the meaning of a requirement text.
When reading technical books, there is usual a chapter in the beginning explaining the meaning of markup, e.g. source code has another font than caveats, examples etc. So even fonts can impose a meaning inside of a requirement text. Although I suggest making things explicit, not always everything is written down in nouns and verbs.
My focus really is on bold, italic, and underline. I'm not sure why somebody would use strikethrough - isn't a key value of having a system that manages requirements having that system generate a report describing what has changed (which is were strikethrough formatting would be used to indicate something was deleted)? If you are manually maintaining record of what gets deleted by using strikethrough formatting, then you are underutilizing a very fundamental capability.
I understand your need, and I agree on not to use strikethrough from a practical point of view. But different people have different needs and workstyles and showing past and new values in the document at hand might be of value for some.
We can't make assumptions on how people use the formatting in the field. The richtext capability uses HTML to encode the markup. And among <B>,<I>, <U> and others, <Strike> is a valid tag that can be used and is supported by the underlying library. To say <B>,<I>,<U> are exempt from creating suspects and other formattings are not (like the ones I sketched above, there are others, like indentation) leaves you in the end with an feeling of uncertainty if your change creates a suspect or not.
It sounds like we've clarified this request. I'd like Integrity to allow admins to specify a "change tolerance" level for rich text fields. There would be several different levels of text change tolerated before firing the suspect link. First level is "none" (default - like current behavior), then you can add additional levels from there.
We are archiving your idea as part of a general review. This action is based on the age of your idea and the total number of votes received, as per this announcement.
You can always post a new idea with all the details required in the form.
Thank you for your participation.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
