Stream: IG creation
Topic: Bug with suppressed messages
Lloyd McKenzie (Dec 19 2021 at 23:44):
At some point, the code on line 56 of SuppressedMessageInformation.jave (within the 'contains' function) was changed from:
if (sm.message.equals(message)) {
to
if (sm.message.contains(message)) {
It needs to change back. The text in the suppressed message must be an exact match, not just a contains check. (Matching against just the message or message + display is already handled elsewhere.) With the code as it is now, I had a suppressed message in SDC that said this:
WARNING: StructureDefinition.where(url = 'http://hl7.org/fhir/uv/sdc/StructureDefinition/sdc-questionnaire-adapt'): The Implementation Guide contains no examples for this profile
However, because this suppressed message contained the 'message' part The Implementation Guide contains no examples for this profile, it was suppressing all occurrences of this message rather than just the specified location. (Meaning I thought I had examples for all of my profiles, when in fact I didn't.) Changing things back corrects this issue.
Sarah Gaunt (Dec 20 2021 at 03:39):
I thought this was done on purpose - so that the suppress warnings files weren't so big and messy. I'm sure that you asked me to clean up one of my suppress files on an FMG call saying that we didn't have to put the full message in anymore. Maybe I'm mis-remembering? But ALL my suppress files now rely on the contains rather than the equals.
Sarah Gaunt (Dec 20 2021 at 03:42):
Not saying it's wrong to change it back to equals, just that it might cause suppress files to stop working.
Lloyd McKenzie (Dec 20 2021 at 04:23):
There are two options - full message, or the message from after the ":" where the preceding part describes the location where the issue was detected. (Grahame's added a couple of additional options, which are the full HTML and the internal key used for the message, though I doubt most people will use those.)
We don't want just a 'contains' test because that will result in suppressing things you didn't intend to. What's happening right now (with the bug) is that if you suppress a full message with location, it will incidentally suppress all occurrences of that message independent of location - and that's definitely not what's wanted.
Sarah Gaunt (Dec 20 2021 at 07:44):
Ah ok, makes sense. Sounds like my suppress files with just the stuff after the : will still work.
Grahame Grieve (Dec 21 2021 at 21:14):
it was done on purpose. And people do use it to suppress messages. The suppressed messages are still shown at the bottom of the page - you would want to check them anyway.
Grahame Grieve (Dec 21 2021 at 21:16):
but I don't want a war over this, so I've changed it so it does a case insensitive equality check unless you have % at the start and/or end of the message
Grahame Grieve (Dec 21 2021 at 21:16):
will be in the next release
David Pyke (Dec 21 2021 at 21:17):
So if you add a %, it's a contain, if not it's an equals. I like that!
Lloyd McKenzie (Dec 22 2021 at 15:17):
'contains' is not safe - at least not when checking location-specific suppression against the 'message'. Key thing is to ensure that if you suppress something location-specific, it can't ever match to a message that isn't from that location. Will the new mechanism ensure that?
Grahame Grieve (Dec 22 2021 at 19:42):
no that's the point: maybe you want to suppress a class of messages. you don't have to use it that way
Lloyd McKenzie (Dec 22 2021 at 20:55):
The issue with the current behavior is I was trying to suppress a message for a specific location. Because of how the code worked, it suppressed the message in all locations. The new mechanism must ensure that if a location is specified in the suppression file, that it only suppresses that location, even if it might happen to 'contain' the location-independent message.
Last updated: Apr 12 2022 at 19:14 UTC
