[IDEA] Reminder for global data pruner setting

[charichu]

Is your feature request related to a problem? Please describe.
When you move around between many mirth installations, it can happen, that you do not enable the data pruner globally, but that you configure the data pruning within channels.
Plenty of engineers have assumed that because they set the data pruner in a channels summary tab, they were all set. This can become a problem quickly when a typical workflow is copying an existing interface without making changes to the previous channel’s settings.

Describe your use case
This feature would assist engineers to not forget the global setting.

Describe the solution you'd like
There should be a notification within the channel summary tab, if the data pruner is disabled globally. So the engineer gets a reminder.

Describe alternatives you've considered
A pop up, while saving changes on the data pruner, that these changes wont have any effect until it is enabled globally, or disabled the whole data pruner section in the summary tab, to show if it is disabled.

[pacmano1]

That seems like a checklist item to me as part of your QA proces, not something that requires a user interface reminder. The main problem to me is that it is an arbitrary reminder in the sense of "how many things should we remind the user to do because perhaps they don't have a good QA/PROD/DEV process?"

[jonbartels]

Workaround

A workaround are queries like this - https://gist.github.com/MichaelLeeHobbs/67980d165fc68880eb2ab283c673244b

Several users in the community use this query (or one like it) to generate a report about the Mirth pruner settings both globally and for each channel.

I have this query set up so that Mirth runs the query, throws an error, and sends an alert if the global pruner is disabled or if any single channel does not adhere to my standards for pruning time ranges.

Possible Solution

What charichu proposes is a good idea. Having a "don't do dumb things" warning is useful in Mirth Connect. The SSL warning screen is one example.

This can be implemented as a client-side plugin. The plugin can generate a popup or a simple warning flag in a menu or status bar.

[charichu]

Thank you for the example query. I will try this out.

Personally, I dont think a QA checklist is superior to an actual implementation, which helps avoid a thing to actually being considered in a QA checklist, but I do understand that limited resources lead to deprioritizing things like these.

Maybe I will comeback to this soon and create my own PR for this, if that would be ok then?

[pacmano1]

I wasn't saying the idea is bad per se - but at some point, for any tool we all use, there can be only so many alert warnings before they are an irritation and people just ignore them and/or they become not helpful. I tend to think catastrophic destruction actions need warnings more than a warning that someone forget to turn something on. For example - how does Mirth alert someone that the mirthdb should be backed up? Not possible. And a QA / checklist item.

[jonbartels]

Maybe I will comeback to this soon and create my own PR for this, if that would be ok then?

Mirth is an open-source project. PRs are always appreciated by the community. The project owner, NextGen Healthcare, sometimes takes time to respond to PRs. They do eventually get to them.

I would strongly suggest writing your own implementation as a Mirth plugin. This means you will be able to write only your code relevant for your pruning goals. It also means that you do not have to compile the whole Mirth app, just a plugin. Finally since it is a plugin, anyone can run it on their instances even if your PR is not accepted. Plugins can also be added to the core product if NextGen wants to.

This guide: https://github.com/kpalang/mirth-plugin-guide is a good review of plugins. If you start a fork or a project, please post a link and the community can take a look.