Ability to set imodel/itwin id's so commands do not require them

[wolfo951]

"Keeping track of id's between commands is a little annoying, is there a way to improve thise interaction or highlight them in the CLI output?

• Longer term is there a "multi-command" setup that makes sense? Like how git bisect enters a "bisecting state" for the repo until you cancel. Maybe like itwin session or itwin open which stores an itwin id and uses that for all subsequent calls until itwin session end or itwin close? could reduce the amount of typing needed"

Allow users to set iModel Id or iTwin Id somewhere somehow, and the commands would reuse them unless the user provides it explicitly or the id storage is reset by the user.

[jjspace]

One thing I thought about with regards to this is using environment variables.
I think it's fairly common that CLI tools will allow setting certain config or arguments using the environment. Something like IMODEL_ID=[id]; itp imodel populate... would work inline but could also be export IMODEL_ID=[id] to set the value and subsequent commands use that? May make sense to require a [Y/n] prompt to confirm the id that's being used (with a -y to skip the check). Maybe that would return to the problem of too many steps though.

Probably other ways to do this, I'd defer to anyone with more experience designing CLIs 🤷

[wolfo951]

From what I gathered, there is an ability to pass down variables from the environment to the CLI flags, but I need to do more testing to make sure it's fully viable.

[wolfo951]

@michelledillard and @roopksaini. During PR review, @Nadegamra highlighted an excellent point, and I agree.

We should verify if the ID that is being used exists. Here are the examples and the workflows proposed:

1. If the user provides --itwin-id only, we just verify that the --itwin-id is valid
2. If the user provides --imodel-id only, we verify that the --imodel-id is valid, and from that we resolve --itwin-id and store it alongside the --imodel-id
3. If the user provides both --imodel-id and --itwin-id, we validate that the --imodel-id is valid and that it has the same iTwinId as provided by the flag --itwin-id

[michelledillard]

@wolfo951 this makes perfect sense to me. Thanks.

[roopksaini]

@wolfo951 This makes sense to me too. In the implementation for steps 2 and 3, It might be good to output if the --itwin-id was updated. So the user is aware what happened behind the scenes.

Examples:
"iModel ID set, the corresponding iTwin ID also updated."
"iTwin ID mismatch found, updating the iTwin ID for the iModel ID provided."
and so forth...

To avoid any confusion why updating --imodel-id changed the --itwin-id.

[wolfo951]

I can add logs to reflect that, but currently, when we execute context set, it returns different responses:

• If only iTwinID is provided, it will return:

{
	"iModelId": undefined,
	"iTwinId": "<iTwinId>"
}

• If only iModelID is provided it will return:

{
	"iModelId": "<iModelId>",
	"iTwinId": "<iTwinId>"
}

• If both iTwinID and iModelID is provided

{
	"iModelId": "<iModelId>",
	"iTwinId": "<iTwinId>"
}

@roopksaini This should be enough feedback for the user.
I would refrain from saving any context when iTwinID and iModelID do not match.

[michelledillard]

@wolfo951 I think this is fine. It reflects that the user did and if the documentation explains how it works, that should be sufficient. If we get feedback otherwise, we can make a change at that time.