Closed t1m0thyj closed 1 month ago
Thank you for raising this issue. The community has 90 days to upvote 👍 the issue. If it receives 10 upvotes, we will move it to our backlog. If not, we will close it.
Related to https://github.com/zowe/zowe-cli/issues/1705
Should this be added to the V3 GA milestone? I'm just wondering if the changes to how Zowe Explorer handles nested APIML profiles would be considered to be a breaking change that we would need to get in before V3 is released.
I've added it to the milestone. Based on offline discussion, I think we determined this should be implemented in V3 to avoid the risk of potential breaking changes.
Here is the planned flow for logging in to API ML for a z/OSMF profile:
graph TD;
baseExists{{Does base profile exist?}};
nestedExists1{{Is zosmf profile nested?}};
nestedExists2{{Is zosmf profile nested?}};
baseTokenized{{Does base profile have\ntokenValue in secure array?}};
storeBase[Store token in BASE profile];
storeParent[Store token in PARENT profile];
cantStore[Cancel operation:\nno profile to store token];
baseExists--Yes-->baseTokenized;
baseExists--No -->nestedExists1;
baseTokenized--Yes-->storeBase;
baseTokenized--No -->nestedExists2;
nestedExists2--Yes-->storeParent;
nestedExists2--No -->storeBase;
nestedExists1--Yes-->storeParent;
nestedExists1--No -->cantStore;
Currently we only support logging in to the APIML for base profiles, and there can only be one active base profile per team config file. If nested profiles like the example below are defined, users may want to log in to multiple APIML instances per team config file. Either Zowe Explorer should also support this scenario, or we should document it as a known limitation.