Add override switch when importing Journeys to automatically overwrite linked config such as scripts where the name matches but UUID is different.

[rockcarver]

Add override switch when importing Journeys to automatically overwrite linked config such as scripts where the name matches but UUID is different.

[vscheuber]

There is a challenge with this request:

Scripts are referenced in nodes by UUID, not by name. So if a collision is detected (collision = a script with the same name or the same uuid but not both) then what would be a predictable and reasonable action to take?

Let's assume the following node in a journey:

"25001c7a-7928-4949-9706-0689416b18b0": {
  "_id": "25001c7a-7928-4949-9706-0689416b18b0",
  "_rev": "-1049667358",
  "script": "50cde102-d4b6-44c4-9ba7-8564af05ae08",
  "outcomes": [
    "true"
  ],
  "outputs": [
    "*"
  ],
  "inputs": [
    "*"
  ],
  "_type": {
    "_id": "ScriptedDecisionNode",
    "name": "Scripted Decision",
    "collection": true
  },
  "_outcomes": [
    {
      "id": "true",
      "displayName": "true"
    }
  ]
}

The above node references the following script:

"50cde102-d4b6-44c4-9ba7-8564af05ae08": {
  "_id": "50cde102-d4b6-44c4-9ba7-8564af05ae08",
  "name": "Select Theme from URL",
  "description": "Select and apply theme from query param in the request URL.",
  "script": "\"/* Select Theme from URL\\n * \\n * Select and apply theme from query param in the request URL.\\n * \\n * This script does not need to be parametrized. It will work properly as is.\\n * \\n * The Scripted Decision Node needs the following outcomes defined:\\n * - true\\n *\\n * Author: [email protected]\\n */\\n(function () {\\n  \\toutcome = \\\"true\\\";\\n  \\tvar theme = \\\"\\\";\\n  \\tif (requestParameters.get(\\\"themeId\\\")) {\\n      \\ttheme = requestParameters.get(\\\"themeId\\\").get(0);\\n    }\\n\\n    var fr = JavaImporter(\\n        org.forgerock.openam.auth.node.api.Action,\\n        org.forgerock.openam.authentication.callbacks.PollingWaitCallback\\n    )\\n    if (theme && callbacks.isEmpty()) {\\n    \\tvar stage = \\\"themeId=\\\"+theme;\\n        action = fr.Action.send(\\n          \\tnew fr.PollingWaitCallback(\\\"100\\\", \\\"Please wait ...\\\")\\n        ).withStage(stage).build();\\n    } else {\\n      \\taction = fr.Action.goTo(outcome).build();\\n    }\\n}());\"",
  "default": false,
  "language": "JAVASCRIPT",
  "context": "AUTHENTICATION_TREE_DECISION_NODE",
  "createdBy": "null",
  "creationDate": 0,
  "lastModifiedBy": "null",
  "lastModifiedDate": 0
}

And now let's assume a switch --override-dependencies or --override-scripts on the journey import command:
What would the predictable action be for frodo to take in the following situations:

1. a script with the same name but different UUID exists
   1. override the existing script with the code of the incoming script (different UUID ) and re-wire the node to reference the existing UUID (what might this do to other nodes referencing the previous version of the script? What if the name was ambiguously generic and the imported script is significantly different from the existing script despite the same name?)
   2. delete the existing script (if possible, what if it is referenced by other nodes and cannot be deleted) and create the incoming script with the same name but different UUID.
   3. rename the existing script to resolve the collision and import the new script with the same name but different UUID (there is no harm to doing this, as names are meaningless in scripts as long as they are unique)
   4. rename the new script and create it with its UUID and a generated new name (that is what frodo is currently doing. there is no harm in doing this, as names are meaningless in scripts as long as they are unique)
   5. are there reasonable alternatives?
2. a script with the same UUID but different name exists
   1. override the existing script with the code of the incoming script (different name) and re-name the script (this is what frodo does today, I believe, and there is no harm in this action because it is unlikely that the same UUID would ever be used by a different script but it is still possible if somebody re-purposed an existing script object)
   2. override the existing script but preserve its name (this seems like an uninteresting option with little benefit)
   3. are there reasonable alternatives?

[vscheuber]

Won't do. If at some point we want to add a user-interactive mode to warn/confirm overrides, we would probably do it for all import operations in the same way. Closing.