frodo idm import -i -f throwing null error

[gwizdala]

Frodo CLI version

Provide output of frodo -v
This issue was originally detected in 3.0.0 but is also in frodo 3.0.1

You are running the homebrew release.
cli: v3.0.1
lib: v3.0.1
node: v20.18.0

Describe the issue

A clear and concise description of what the issue is.

Historically, I could import the raw json from either a REST call or an older version of Frodo (without the metadata) into idm using the -i flag to specify the entity. However, since version 3+, I run into the following error:

frodo idm import -i alphaOrgPrivileges -f alphaOrgPrivileges.json gwiz-sandbox
Connected to https://openam-<tenant>.forgeblocks.com/am [alpha] as service account Frodo-SA-number [guid]
Cannot convert undefined or null to object

If I add the wrapping json from the new idm exports, the import with the same command works as expected.

This is a painful change as it eliminates cross-compatibility with Frodo and the platform (e.g. using REST or idm queries), and has resulted in me having to manually update JSON objects either by removing or adding the wrapper.

This also invalidates the -A command, as it is supposed to read the contents of a directory and identify the objects with or without the json metadata.

[vscheuber]

@phalestrivir @hfranklin I believe this was caused by some of the recent changes for 3.x. Let's discuss how and if we can fix this.

I believe this is just one more example of the 2nd class citizen role IDM plays in the Frodo CLI command structure, today.

[phalestrivir]

@vscheuber Yes, I updated the IDM exports to be consistent to how the rest of Frodo does exports as part of the 3.0.0 changes. For example, originally for sync mappings it would export the raw json into a file named sync.json. Now it exports into a file named sync.idm.json, and in the following format:

{
  "idm": {
    "sync": { ... }
  }
}

Where { ... } is the raw json that was originally contained in sync.json. This matches how we currently do it for all the AM config which also takes the raw json data from the AM REST API and saves it to a file in this format where it is wrapped by the type of the config entity.

I'm thinking if we want to support the raw json data as well we could have a flag such as -r, --raw as part of the export and import to indicate that we want to export/import raw json data only. I think this would work in every case except when doing a full configuration import with the frodo config import command which relies mostly on the wrapper to determine the type of the data being imported (and in this case we could maybe use the directory structure of the export to figure out all the types instead).

Another option we could do is assume it's raw if it's not in the format we expect, although I feel like that could be risky and potentially lead to other problems such as importing JSON data that we shouldn't. I think leaving it in the hands of the user to decide if they are importing raw or formatted data through use of a flag might be best.

What are your thoughts on this @vscheuber and @hfranklin?

[phalestrivir]

@vscheuber @hfranklin Just following up on my last comment. How should we go about resolving this issue?

[vscheuber]

@phalestrivir I agree with your assessment. We've had commands using --raw before (saml commands) and I don't want to attempt and auto-detect user intentions. In my mind: proceed with your suggested approach. @hfranklin ?