Fix rendering objects in default profile values (both web-help & terminal based help)

[sosadchuk]

Hello,

We have one of our profile properties defined as follows:

  public static DBMDB2_CONNECTION_OPTION_ENVIRONMENT_LIST: ICommandOptionDefinition = {
    name: "environment-list",
    aliases: ["el"],
    description: `...`,
    defaultValue: {
      ssid1: "env1@host1:port1",
      ssid2: "env2@host2:port2"
    },
    type: "string",
    required: false,
    group: dbmDb2CommandOptionDefinitions.DBMDB2_CONNECTION_OPTION_GROUP
  };

For both V1 profiles and team configuration, the value is saved without any issues, but in the web-help and terminal we see:

I assume we are supposed to provide a string value here, but that's the problem with defaults - while we can use a custom create/update handler for V1 profiles, we don't have a mechanism to convert string values (as we expect them to be provided) for team configuration.

The same limitation forces users to use --json flag while updating such fields in team configuration. But that's another story I guess, would be nice to see the string representation of the object at least.

Thanks, Sergei.

[t1m0thyj]

In the example option definition that you provided, the defaultValue and type don't match. I would expect the definition to be one of the following:

    defaultValue: {
      ssid1: "env1@host1:port1",
      ssid2: "env2@host2:port2"
    },
    type: "json",

    defaultValue: `{\n  ssid1: "env1@host1:port1",\n  ssid2: "env2@host2:port2"\n}`,
    type: "string",

Could you please clarify which is the intended behavior for this option?

[sosadchuk]

Hi @t1m0thyj , the intent here was to have a nice profile with values defined as follows:

• for V1

environmentList:
    ssid1: env1
    ssid2: env2

• for V2 / team config

"environmentList": {
    "ssid1": "env1",
    "ssid2": "env2"
},

If we use the json type - we will get something like environmentList: "{\n \"ssid1\": \"env1\",\n \"ssid2\": \"env2\"\n }" for both, which makes it harder to edit and parse if needed. I believe we'll get the same result if we use the string type.

So currently we used the string type for the input (ICommandOptionDefinition), and the object type for saving (IProfileProperty). This results in a valid yaml objects for v1, and a valid json object for team configuration for defaults.

During updating this property we expect users to use the --json flag for team config, and for v1 we use own profile update handler to convert a string value to an object.

[zFernand0]

If the option type is a string and the default value is not a string, we could JSON.stringify the default value.

[gejohnston]

Accidentally closed this issue. Reopening this issue.

[github-actions[bot]]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs.

[github-actions[bot]]

This issue has been automatically closed due to lack of activity. In an effort to reduce noise, please do not comment any further.