Add configurable channel clone dialog

[eddcomeau]

Summary

Implements Issue #153 by adding a configurable channel clone dialog.

#153

Users can now choose what to copy when cloning a channel, including:

• Channel name, with validation
• Prune settings
• Group membership
• Tags
• Outbound channel dependencies
• Code Template Library assignments
• Shared resource assignments

The clone receives a new GUID and revision zero, preserves the source channel, and opens in the normal channel editor for review before saving.

Additional fixes

• Default clone name is <source name>1.
• Tags use the shared channel-tag association path so they persist correctly and appear in Settings → Tags.
• Inbound dependencies are not copied or modified.
• Existing clone behavior remains available through the new dialog.

Testing

• Client compilation passes with:

.\gradlew.bat :client:compileJava --no-daemon

Compiled and tested in the Client/Server on Windows10:

• Dependencies are carried over and can be toggled.
• Prune Settings are carried over and can be toggled.
• Tags are carried over and can be toggled.
• Group Membership are carried over and can be toggled.
• Code Templates are carried over and can be toggled.
• Resources are carried over and can be toggled.

Hard to capture in pictures, but proof that I went in and tested the endpoints at least.

[jonbartels]

Users can now choose what to copy when cloning a channel

Can you show what the selection dialog looks like? Add it as an edit to the issue description.

[github-actions]

Test Results

655 tests ±0 655 ✅ ±0 2m 10s ⏱️ +56s
109 suites ±0 0 💤 ±0 
109 files ±0 0 ❌ ±0 

Results for commit a1942a2. ± Comparison against base commit 776690e.

[mgaffigan]

Thanks for the PR! I'm not blocking if you have three other reviewers.

Over time, we have to simplify the core channel operations - this is a perpetuation of the global state everywhere with logic on the client.

I'd prefer to see either:

• if clone does not require service calls: a new "clone" method on channel that returns the unsaved object for edits
• if clone requires service calls: a new "clone" service operation that takes a source channel ID and clone options, and returns the new channel

I would caution against overcomplicating a clone dialog: after clone, the user must edit the channel anyway, and all the editors are existing in that interface.

I think this is also likely related to:

• move channel group membership to be a property of channels, not of groups
• move channel code template use to be a property of channels, not of code templates

Those refactorings may substantially simplify the clone process.

[mgaffigan]

This is already a very large and overcomplicated file. Can we avoid clone logic being added here?

[mgaffigan]

More global state? Can we avoid?

[eddcomeau]

Thanks for the PR! I'm not blocking if you have three other reviewers.

Over time, we have to simplify the core channel operations - this is a perpetuation of the global state everywhere with logic on the client.

I'd prefer to see either:

• if clone does not require service calls: a new "clone" method on channel that returns the unsaved object for edits
• if clone requires service calls: a new "clone" service operation that takes a source channel ID and clone options, and returns the new channel

I would caution against overcomplicating a clone dialog: after clone, the user must edit the channel anyway, and all the editors are existing in that interface.

I think this is also likely related to:

• move channel group membership to be a property of channels, not of groups
• move channel code template use to be a property of channels, not of code templates

Those refactorings may substantially simplify the clone process.

I appreciate this. I think if I do go the route you talk about here I would do it in a new PR rather than try to salvage this branch. I might leave this up in case the team thinks this is a worthwhile addition in the meantime.

I’ve been thinking about the longer-term roadmap:
Move channel group membership to the channel side of the model.
Move channel code-template-library assignments to the channel side, with library views deriving their channel lists.
Move channel tag associations to the channel side, while retaining shared tag definitions.
Implement cloning as a dedicated service operation that accepts clone options and returns the new channel.

That all sounds daunting, especially thinking about channel export/import and the need to change server/client/CLI portions in conjunction. Selfishly I like MirthSync and I don't want to stray too far on our export structure. But I haven't thought too hard about these, so I will commit to looking into them at least!

[eddcomeau]

Users can now choose what to copy when cloning a channel

Can you show what the selection dialog looks like? Add it as an edit to the issue description.

I added it up there thanks