Feature: Add recent filters drop-down to the message browser

[mgaffigan]

Adds a recent button to the message browser pane. Allows restoration of the last 10 searches on the channel.

Closes #273

[github-actions]

Test Results

  112 files  +1    216 suites  +2   7m 4s ⏱️ + 1m 16s
  654 tests +3    654 ✅ +3  0 💤 ±0  0 ❌ ±0 
1 308 runs  +6  1 308 ✅ +6  0 💤 ±0  0 ❌ ±0 

Results for commit 2a5b15c. ± Comparison against base commit d4d1122.

♻️ This comment has been updated with latest results.

[Copilot]

Pull request overview

Adds a “Recent…” drop-down to the Message Browser so users can quickly re-apply the last ~10 searches per channel, backed by persisted client preferences. To support MRU de-duplication and display text, the shared MessageFilter model gains equality logic and a new criteria-oriented string formatter.

Changes:

• Add client-side storage for per-channel recent message filters (persisted in user preferences) and a “Recent…” UI button to restore them.
• Add applyFilter(...) plumbing to push a saved MessageFilter back into the advanced filter UI.
• Enhance shared filter model objects with equals/hashCode and add new test coverage around equality / criteria formatting.

Reviewed changes

Copilot reviewed 7 out of 7 changed files in this pull request and generated 5 comments.

Show a summary per file

File	Description
server/test/com/mirth/connect/model/MessageFilterModelTest.java	Adds unit tests covering MessageFilter equality, emptiness semantics, and criteria-string output.
server/src/com/mirth/connect/model/filters/elements/MetaDataSearchElement.java	Implements equals/hashCode for metadata search elements (enables deep equality in filters).
server/src/com/mirth/connect/model/filters/elements/ContentSearchElement.java	Implements equals/hashCode for content search elements (enables deep equality in filters).
server/src/com/mirth/connect/model/filters/MessageFilter.java	Adds deep equality + isEmpty(), and introduces a criteria-style toString(Map, padding, includeEmptyCriteria) used by the client.
client/src/com/mirth/connect/client/ui/browsers/message/MessageBrowserRecentFilterStore.java	New preference-backed store for MRU MessageFilter lists per channel.
client/src/com/mirth/connect/client/ui/browsers/message/MessageBrowserAdvancedFilter.java	Adds applyFilter(...) to restore advanced selections from a saved MessageFilter.
client/src/com/mirth/connect/client/ui/browsers/message/MessageBrowser.java	Adds “Recent…” button/menu, saves filters on search, and reuses MessageFilter.toString(...) for the criteria pane.

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[NicoPiel]

Great feature. Will look at the code as soon as I am able to.

[jonbartels]

Pretty nice! Left two comments for improvements to property handling and maybe a simpler data structure

[pacmano1]

This feature may leave PII and PHI locally on a workstaiton. So in its current storage format, it's a no for me.

[pacmano1]

Can leave PII/PHI on local workstation. Storage format needs to be changed.

[gibson9583]

This feature may leave PII and PHI locally on a workstaiton. So in its current storage format, it's a no for me.

agree that PII/PHI is a risk. Perhaps we should rethink how this works? While it may negate how useful this is, perhaps this is cleared on user logout? If thats the case, maybe we then dont cache by channelId but rather global so user doesnt have to build the cache on every channel.

[pacmano1]

This feature may leave PII and PHI locally on a workstaiton. So in its current storage format, it's a no for me.

agree that PII/PHI is a risk. Perhaps we should rethink how this works? While it may negate how useful this is, perhaps this is cleared on user logout? If thats the case, maybe we then dont cache by channelId but rather global so user doesnt have to build the cache on every channel.

admin session can be terminated without logout.

[mgaffigan]

@pacmano1 / @gibson9583

This feature may leave PII and PHI locally on a workstaiton. So in its current storage format, it's a no for me.

agree that PII/PHI is a risk. Perhaps we should rethink how this works? While it may negate how useful this is, perhaps this is cleared on user logout? If thats the case, maybe we then dont cache by channelId but rather global so user doesnt have to build the cache on every channel.

I agree with the concern, but think storing any text search only in memory or in preferences is likely sufficient. I'll update the PR to address the unencrypted-local-storage of text searches.

[gibson9583]

@pacmano1 / @gibson9583

This feature may leave PII and PHI locally on a workstaiton. So in its current storage format, it's a no for me.

agree that PII/PHI is a risk. Perhaps we should rethink how this works? While it may negate how useful this is, perhaps this is cleared on user logout? If thats the case, maybe we then dont cache by channelId but rather global so user doesnt have to build the cache on every channel.

I agree with the concern, but think storing any text search only in memory or in preferences is likely sufficient. I'll update the PR to address the unencrypted-local-storage of text searches.

in-memory is good with me. It doesnt need to survive client restart. Preferences is the only issue I can see because that is stored unencrypted and available to any process on server.

[mgaffigan]

@pacmano1 / @gibson9583, updated to use in-memory storage only. That's tantamount to the rest of the PHI which already resides in memory.

[kpalang]

Some suggestions and nitpicks, but overall a nice implementation.

Comments formatted as conventional comments.

[kpalang]

Approved.

I found one small improvement after the previous review, but it is small and I'm not gonna request a change for this.

[NicoPiel]

Great stuff.

[tonygermano]

This non-blocking, but the ToString, Equals, and Hash builders in lang3 could probably reduce the lines of code and avoid manual string building.

I approve of the recent filters being saved in memory only. If we persist them in the future, I think it should be a database-backed user preference rather than a local java preference.

Either way it could get complicated if the user has more than one admin client open at the same time.

A future feature request could be the ability to pin or "forget" a recent search to have a little more control in keeping useful requests around longer.

pacmano1 requested the information not be persisted locally. It is no longer persisted locally. No response on re-review.