Inconsistent deployment type registration in config-manager commands

[vscheuber]

Frodo CLI version

Provide output of frodo -v

Describe the issue

Inconsistent deployment type registration in config-manager commands. I reviewed every config-manager pull and push command module for the declared deployment types.

Overall

• Cloud + ForgeOps: 37 commands
• Cloud-only: 9 commands

Pull Commands

Command	Deployment types
access-config	cloud, forgeops
all	cloud, forgeops
all-static	cloud, forgeops
audit	cloud, forgeops
authentication	cloud, forgeops
authz-policies	cloud
connector-definitions	cloud
connector-mappings	cloud
cookie-domains	cloud, forgeops
cors	cloud
csp	cloud
email-provider	cloud, forgeops
email-templates	cloud, forgeops
endpoints	cloud, forgeops
internal-roles	cloud, forgeops
journeys	cloud, forgeops
kba	cloud, forgeops
locales	cloud, forgeops
managed-objects	cloud, forgeops
oauth2-agents	cloud
org-privileges	cloud
password-policy	cloud, forgeops
raw	cloud
remote-servers	cloud, forgeops
saml	cloud, forgeops
schedules	cloud, forgeops
scripts	cloud
secret-mappings	cloud, forgeops
secrets	cloud, forgeops
service-objects	cloud, forgeops
services	cloud, forgeops
terms-and-conditions	cloud, forgeops
test	cloud, forgeops
themes	cloud, forgeops
ui-config	cloud, forgeops
variables	cloud, forgeops

Push Commands
All push subcommands are cloud + forgeops:

• email-provider
• email-templates
• endpoints
• internal-roles
• kba
• locales
• password-policy
• schedules
• terms-and-conditions
• themes

It raises the bigger question if we can/want to support config-manager commands across both cloud and forgeops or for cloud only.

Obviously there are nuances in ESVs and other clound environment APIs, which do not apply to forgeops but only to cloud. Then there is the question how the pull all and push all commands would be expected to work if we decided to support both.

I've been working on a new help framework based on Commander 14 (15 is ESM only and our binary builds currently require CJS, so I didn't go all the way to 15). In this new help framework, I am dramatically reducing unnecessary help output and a lot of that is controlled by supported deployment types per command. So having the correct deployment types specified for each command is going to become even more important than it is now.

Let's discuss config-manager in particular in this issue.

[hfranklin]

@vscheuber I'm guessing the inconsistency in deployment types between config-manager commands is an artifact of when they were developed. We are using forgeops for 90% of our testing now, so I expect most of the commands to support both cloud and forgeops. After the initial implementation is complete, I'm thinking we will extend support for self-managed AM and IDM.