Set hide options for single plugin in filter

[MacSplody]

So I've seen it come up a few times that users want to hide a message for a plugin but keep others.

Currently all messages are filtered by type for all plugin.

So what could work is have a plugin selection the same as the conflict filter, which would default to all plugins. If the user selects a plugin then they could select hide options only for that plugin.

Another option would be to have a hide option in the plugin metadata editor.
Something like a eye icon to toggle hide\ignore for individual messages.

[Ortham]

Having a hide icon for each message seems like a better fit, coupled with an option to see hidden messages and so show an icon un-hide each of them. The feature needs a better name to distinguish it from the sidebar filters - maybe dismissed messages instead? That, or maybe the message filters would be better repurposed to be like bulk-clicking the hide button for all the messages that match?

Another question would be how to identify messages so that they can be hidden reliably - going by index (e.g. the fourth message on X.esp) doesn't seem reliable enough (what if one gets inserted before it, how would it interact with generated messages?), so I'd lean towards hashing the plugin name, message type and message content (as displayed, not what's in the masterlist). That would mean that rewording / fixing typos would cause the message to be displayed again, but I think false negatives are preferable to false positives.

[MacSplody]

The feature needs a better name to distinguish it from the sidebar filters - maybe dismissed messages instead?

Dismiss would be fine, what would be the opposite, restore?

so I'd lean towards hashing the plugin name, message type and message content (as displayed, not what's in the masterlist). That would mean that rewording / fixing typos would cause the message to be displayed again

So if they dismissed a message, update their master list, and the master list has since changed that message, it would display it like a new message.
Yeah, that would be better, I assume that would cover additions to localization?

[Ortham]

Dismiss would be fine, what would be the opposite, restore?

Not sure, naming this is hard.

Yeah, that would be better, I assume that would cover additions to localization?

Only if that changed the displayed text. E.g. if a user was running LOOT in English and a dismissed message had a French translation added, that wouldn't restore the message, but if they were running in French, then the change from English text to French text would restore the message.

[superelitist]

A given message is derived from a particular entry in the masterlist, right? Could it be masked by some sort of .lootignore file, a YAML of plugins/messages NOT to process?

I don't know about the UI implementation, though.

[pStyl3]

A specific use case where it would be useful to hide individual messages is the following one.

Skyrim Special Edition+Anniversay Edition Update. One of the Creation Club plugins that make up the AE update is ccbgssse018-shadowrend.esl. If SSE is set be displayed in English, SSEEditQuickAutoClean's report for the plugin is:

  - name: 'ccbgssse018-shadowrend.esl'
    dirty:
      - <<: *quickClean
        crc: 0xEDDE17F4
        util: '[SSEEdit v4.0.4](https://www.nexusmods.com/skyrimspecialedition/mods/164)'
        itm: 1
    clean:
      - crc: 0xCB639341
        util: 'SSEEdit v4.0.4'

If the game is set to be displayed in German, it is:

  - name: 'ccbgssse018-shadowrend.esl'
    clean:
      - crc: 0xEDDE17F4
        util: 'SSEEdit v4.0.4'

The same goes for xEdit v4.0.4b.

So the user of German SAE sees in LOOT that ccbgssse018-shadowrend.esl has 1 ITM, tries to clean the plugin in xEdit, xEdit doesn't clean the record because of it's German master files the record isn't technically ITM - and then they continue to see the message in LOOT.

The likelihood of this happening should be pretty low, especially if the number of dirty edits is high. However with only a singular ITM, the chance grows for such things to happen. If users could hide individual messages in LOOT, they could hide QAC reports that, in a rare case, do not apply for them & if it bothers them.

[lufusol]

A simple "don't show me this message again" next to each, which adds the message ID to a blocklist stored locally which is checked against after each time LOOT completes a run, and those messages suppressed or removed before the output is assembled and/or presented to the user. Plus a flag set if any messages WERE suppressed and if true, add a note at the top of the final output "Some messages have been hidden" and a link "show me", restoring and presenting the pre-filtered version of the list to the user, just that one time. Maybe, in that case, an "unhide" link next to each, if you want to remove that message's ID from the blocklist for next time

A deeper setting in the options to turn the whole feature on or off, and maybe a nuclear reset button. That's all I could ever ask for.