feat: allow users to select their tenant when creating publish profiles #6542
Conversation
Old profiles for users in a single tenant will continue to work. If a user is in multiple tenants, their publish will fail and they will need to recreate their publishing profile or add tenantId to the publish configuration.
a-b-r-o-w-n
requested review from
GeoffCoxMSFT,
beyackle,
boydc2014,
cwhitten,
hatpick,
srinaath and
tonyanziano
as code owners
tonyanziano
left a comment
tonyanziano
left a comment
There was a problem hiding this comment.
A few minor comments. Otherwise looks good 👍
extensions/azurePublish/src/components/azureProvisionDialog.tsx
Outdated
Show resolved
Hide resolved
extensions/azurePublish/src/components/azureProvisionDialog.tsx
Outdated
Show resolved
Hide resolved
|
regarding:
How is this presented to the user? |
|
@a-b-r-o-w-n is this the behavior today without this change, or are you adding it as a constraint?
For example, I have access to more than one tenant, but I can also successfully publish on existing profiles. Will I be broken? |
|
@cwhitten I don't fully understand all the scenarios and why some were working while others were failing, but I suspect that the tenant being used implicitly was the correct one. This change forces you to be explicit about which tenant to publish to. Not sure if that clears anything up. I could revert back to the old method (just choosing the first tenant) and not show the notification which would be in parity with what we do today. What do you think? |
|
Makes sense. I'm of the mind to preserve existing behavior so we don't break people, and when we see an error about tenant mismatch we render the notification as you have and suggest they modify their profile or create a new one. @mewa1024 @emivers8 we could use a UX assist here. We need to bring this functionality in so users with access to multiple tenants can publish deterministically. Without it there are potential mismatches with other information in the provisioning profile resulting in publishing failures. We also don't want to break people where this is working as expected. It's likely due to the "default" tenant that they have set up happens to be the right one with all the services they are provisioning and publishing to. Attached is an example mismatch
|
|
@cwhitten sorry for the delay in reply. Just want to make sure I understand the solution:
So in this screen (from Composer 1.4 nightly), we would have an additional dropdown for "Azure directory" above "Subscription" for both new profiles and existing profiles that a user edits:
Is that summary right? So when a user is signed in to Azure, we don't sign them into a specific tenant? In other words, unlike the Azure portal or LUIS.ai, where when you sign in you choose a tenant that you use for the entire session. There is a control for switching tenants separate from the UI where you create/choose resources:
If we need an Azure sign in control, it could go in the in the main menu above the gear, similar to this from VS Code: |
|
@mewa1024 see below:
Correct
Not always. If the information in the profile is associated with the "default" tenant, it works successfully. If the default tenant was changed, they would see an error.
Correct The tenant/directory selection currently happens when you sign-in to azure, not when you are selecting resources. @a-b-r-o-w-n are you able to share a gif or screenshot of this for @mewa1024 ? |
This is sort of true. There is a new page in between selecting resources and the initial sign-in. The flow works like this:
Screen.Recording.2021-03-25.at.9.30.03.AM.mov |
|
Ahh, I got it. Following up w/ you on Teams |
|
fyi, Andy, Jas, and I talked offline. Andy figured out how to make the sign in work without the second approval step, so we can move the Azure tenant selector to the same screen where you pick the subscription etc should work. Jas updated screen here: (Zooming out in the Figma file shows the latest provisioning flow.) |
Nice! |
|
@a-b-r-o-w-n @cwhitten Can we get this checked in soon? We have a whole set of work in these files for publishing and one involves deferring sign in until later in the process so we can't really work on that until this is checked in. :) |
Yep, planning to get it in this morning |
…es (microsoft#6542) * feat: allow users to select their tenant * clear login error after successful login * show sign in copy before configure resources * require tenantId on new publishing profiles Old profiles for users in a single tenant will continue to work. If a user is in multiple tenants, their publish will fail and they will need to recreate their publishing profile or add tenantId to the publish configuration. * update error message when publish profile is no longer supported * use formatMessage for strings * maintain existing flow but catch mutliple tenants error * open dev tools when running electron * do not take focus away for electron debug task dependencies * show tenant selection ui when configuring resources * use internal logic to persist tenant id to publish profile * remove unused import Co-authored-by: Chris Whitten <christopher.whitten@microsoft.com> Co-authored-by: Geoff Cox (Microsoft) <gcox@microsoft.com>
Description
If a user is a member of more than 1 tenant, a new tenant selection UI is shown before they can configure a new publish profile.
Breaking change: New publish profiles will encode the tenant that was selected to be used for fetching arm tokens. Old profiles will continue to work ONLY if a user is a member of a single tenant. Users that are in multiple tenants must either add the correct tenant id to the existing profile or create a new profile.