When using Minions, it is common to have more than one per location to guarantee that requests to a given location will always be processed, even if one Minion fails, or to split load when processing lots of Syslog messages Traps, or Flows.
Historically, a placeholder called %dpname% is part of the reduction-key and clear-key for all the event definitions with alarm-data.
When there are Minions involved, that placeholder is replaced at runtime with the Minion ID, which can lead to problems with the alarm life cycle, breaking the logic to decide whether or not an alarm should be cleared.
For instance, one Minion can receive a trigger event, and its sibling can receive the corresponding rearm event. Then, the alarms generated will have different content for the %dpname%, and because of that, there is no way that the trigger event will be cleared because the clear-key of the rearm event will never match the reduction-key of the trigger event.
A solution could be removing that placeholder from all the event definitions with alarm-data, but that will make upgrades complicated, as essentially all the event definition files will appear as changed.
Also, there might be scenarios when having %dpname% makes sense.
For this reason, I believe it would be useful to have a flag to ignore the %dpname%, so for the users that are affected due to the broken alarm life-cycle can use OpenNMS the way it works when Minions are not involved while keeping compatibility with the current behavior, in case, there is a justification for it.