[jeremy-gooch-sp]

Description

This PR adds a rename command to ui-plugins. Since update in plugins is already reserved for pushing hand edits to the plugin manifest, introduced the new rename verb specific to ui-plugins.

How Has This Been Tested?

Steps in MV CSTM-564

[patrick-dowd-sp]

LGTM

[scott-phillips-sp]

Does this handle multiple tenants? Lets say I have the plugin installed on my production and sandbox tenant, and now want to rename it? What does the flow look like?

[jeremy-gooch-sp]

This rename command supports renaming both the name and alias. To change just the name, the flow would look like:

    sail ui-plugins rename --env prod --name "New Name"      # patches prod + updates the file
    sail ui-plugins push-manifest --env sandbox              # resolves the same alias, pushes the manifest

For the alias, since that's how different plugins with different ids are identified cross tenants, once it's renamed that connection in the second tenant is effectively severed. Therefore updating the alias in both tenants with the command as it is here would require resetting sp-ui-plugin.json like:

    sail ui-plugins rename --env sandbox --alias new-alias
    git checkout -- sp-ui-plugin.json          # back to old alias
    sail ui-plugins rename --env prod   --alias new-alias

I think first class support of the renaming of aliases cross tenant in this command group will feel clunky which ever way we go, but there might be a way to soften the friction. For instance we could offer to not change sp-ui-plugin.json by asking if they have the plugin installed in a different tenant. Granted they will have to eventually update sp-ui-plugin.json after the last instance is renamed and communicating that might be tricky. For instance, if they opt to rename the alias then present them with:

sp-ui-plugin.json stores the alias the CLI uses to find this plugin in each tenant. If the same plugin is installed in more than one tenant (for example, sandbox and production), rename every instance before you save: the saved file points the workspace at the new alias, and any tenant still on the old alias can no longer be found by rename until it's renamed too.

• Answer No if you still have other tenants to rename — keep the current file, switch with –env, and rename each one.
• Answer Yes if this is the only instance, or the last one you're renaming.

Write these changes to sp-ui-plugin.json now? [y/N]

Or, we could just drop the ability to rename aliases and accept it as an unsupported gap.

[scott-phillips-sp]

Hmm, Could we just have it be something like this:

sail ui-plugins rename .... # this updates the sp-ui-plugin.json manifest file with the new alias.

sail ui-plugins push-manifest # Upon push manifest ums picks up the rename and makes it active for that tenant.
sail env use X
sail ui-plugins push-manifest # Push the manifest to the next tenant. 

So the thought is the CLI rename command just updates the manifest file, then we update push-manifest on the UMS side to handle the rename on the server side? It's smart enough to see that it's the same id with a new alias. When you complete the rename command it should have console output telling you to run psuh-manifest? Or am I skipping over some complexity?

[jeremy-gooch-sp]

The main gap is that the CLI looks up the id by the alias. The id is not stored in the manifest as it's different in different tenants. So, if you rename the alias in the manifest you cannot then do a push-manifest afterwards.