[IDEA] Keep `Migratable` and `MigratableConverter` up to date for each new release.

[sbraconnier]

Is your feature request related to a problem? Please describe.
When developing complex custom plugins (take the SSL plugin as example, which adds some configuration within a channel/connector serialized configuration), we need to be able to count on something when it is time to migrate model classes during deserialization to a newer version of the plugin. You can implement the com.mirth.connect.donkey.util.migration.Migratable interface for that, but unfortunately it wasn't properly maintain by the Mirth developers team. They added a new version to this class only when they needed it.

Describe your use case
When developing custom plugins with model classes that could potentially have to be migrated at some point, it would be nice to have a strategy we can count on for each OpenIntegrationEngine release.

Describe the solution you'd like
Integrate in the release TODOs list the task to update the com.mirth.connect.donkey.util.migration.Migratable and com.mirth.connect.model.converters.MigratableConverter classes with the missing code required for the serializer to update a model class on deserialization, even if it's not required for any model classes of the engine release. It would offer plugin developers a way to update their model classes on OIE upgrade.

Describe alternatives you've considered
I didn't consider anything else. Maybe using a com.mirth.connect.server.migration.Migrator class configured in a plugin.xml file, but it would be a PITA (if a use again the example of the SSL plugin) to update the XML of all the channels by parsing the XML as a String. Probably not the best way to to it.

Additional context
I wonder how this migration stuff will evolve for plugin developers with multiple mirth branches in the mix. It will be hard to count on that strategy if you want to be able to support both OpenIntegrationEngine and BridgeLink, for example.

Maybe someone knows a better way to handle this.

[mgaffigan]

@sbraconnier, is this relating to migrating server versions or plugin versions? I presume plugins would version separately.

[sbraconnier]

@mgaffigan Well, I would say "both" at the moment. Let me explain with a real example. I created a channel with an HTTP Listener as source connector. The HTTP Listener uses a (provided) plugin to manage HTTP Authentication. Here's the XML when you export that channel (only the interesting part):

<channel version="4.5.2">
  <id>7e892b18-32db-4269-97a6-65fd29d80b60</id>
  <nextMetaDataId>2</nextMetaDataId>
  <name>Test</name>
  <description></description>
  <revision>1</revision>
  <sourceConnector version="4.5.2">
    <metaDataId>0</metaDataId>
    <name>sourceConnector</name>
    <properties class="com.mirth.connect.connectors.http.HttpReceiverProperties" version="4.5.2">
      <pluginProperties>
        <com.mirth.connect.plugins.httpauth.basic.BasicHttpAuthProperties version="4.5.2">
	      <authType>BASIC</authType>
          <realm>My Realm</realm>
          <credentials class="linked-hash-map">
            <entry>
               <string>test</string>
              <string>test</string>
            </entry>
          </credentials>
          <isUseCredentialsVariable>false</isUseCredentialsVariable>
          <credentialsVariable/>
        </com.mirth.connect.plugins.httpauth.basic.BasicHttpAuthProperties>
      </pluginProperties>
...

Since the plugin BasicHttpAuthProperties implements the com.mirth.connect.donkey.util.migration.Migratable, the actual version of the engine is added into the XML on serialization. Suppose you remove the isUseCredentialsVariable from the BasicHttpAuthProperties configuration starting at version 4.5.3, you would then override the migrate4_5_3 method of the Migratable interface and manipulate the DonkeyElement to remove the isUseCredentialsVariable during deserialization, avoiding errors on channel deserialization when you migrate to version 4.5.3 or when you import a channel exported with an older version (<4.5.3).

But for that to work, the om.mirth.connect.donkey.util.migration.Migratable#migrate4_5_3 must exist and must be called in the com.mirth.connect.model.converters.MigratableConverter#migrateElement method:

if (MigrationUtil.compareVersions(elementVersion, "4.5.3") < 0) {
    instance.migrate4_5_3(element);
}

It would probably be better to have a solution specific for plugins migration, but for now if we could at least be able to count on the Migratable interface, it would be a nice improvement.