We now have guest access in Project for the web, but in the early testing we have seen some anomalies raised by customers (and MVPs - thanks Erik and Paul). There are a lot of settings across M365 that control what guests can do - but none appeared to explain the difference we were seeing from tenant to tenant. So, what was different and what can you do about it? First, I'll explain the difference I was seeing.
In one tenant (see screenshot above) I could add an existing guest (you can't invite new guests from Project - that is expected) and it allowed me to choose between adding them to the group or just making an assignment. I could also add them manually to the members list. All good! In my other test tenant, I could add them to a task, and they were assigned - but not added to the group - and listed instead as "other people" - and I couldn't see them listed to add them to a group - at least in Project (I could in Outlook or AAD).
On the face of it everything looked the same about the guest user (it was the same account) and even the tenant. A quick play around with F12 developer tools and I could see when I browsed to add a new member and it was not finding the guest, the actual query had a filter - "userType%20ne%20%27Guest%27" - so not suprising that my guest wasn't found! I then tried Ctrl-F5 to fully refresh the page and look through the other calls going to the service, to see if there was any clue to why it wasn't looking for guests. These few calls looked like they were getting various settings that might impact the page:
and without too much looking I found that "GroupSettings" looked interesting. It was calling out to an API to get TenantSetting/GroupSettings. The response it got was {"value":[]} - basically a NULL array. Odd. I tried the same thing on my working tenant and saw the response as this:
{"value":[{"displayName":"Group.Unified","templateId":"62375ab9-6b52-47ed-826b-58e47e0e304b","id":"3c4adb15-25c8-48a5-b060-106e025803a2","values":[{"name":"NewUnifiedGroupWritebackDefault","value":"True"},{"name":"EnableMIPLabels","value":"True"},{"name":"CustomBlockedWordsList","value":""},{"name":"EnableMSStandardBlockedWords","value":"False"},{"name":"ClassificationDescriptions","value":""},{"name":"DefaultClassification","value":""},{"name":"PrefixSuffixNamingRequirement","value":""},{"name":"AllowGuestsToBeGroupOwner","value":"False"},{"name":"AllowGuestsToAccessGroups","value":"True"},{"name":"GuestUsageGuidelinesUrl","value":""},{"name":"GroupCreationAllowedGroupId","value":""},{"name":"AllowToAddGuests","value":"True"},{"name":"UsageGuidelinesUrl","value":"https://guideline.example.com"},{"name":"ClassificationList","value":""},{"name":"EnableGroupCreation","value":"True"}]}]}
This looked familiar as I'd set some of these values in the past using PowerShell. A great article that describes all this can be found at Azure Active Directory cmdlets for configuring group settings . I looked at both of my tenants to see what settings were present, using Get-AzureADDirectorySetting -All $true. My tenant that didn't resolve the guest came back empty:
In my tenant that did show some settings I saw what I expected:
It appeared that I had no specific settings configured, and in that case the NULL array returned didn't give Project the information it needed to know that guests were ok to resolve. I'm not sure at this point whose bug this is - Azure AD for not having any defaults show up - or Project for not filling in the gaps. We will see who gets to fix it. But to fix it yourself you just need your tenant admin to follow steps in the article listed above to set the settings they want - and assuming they don't block guests you should then be able to assign and add guests to your projects and they will be members. CTRL-F5 once the Group Settings are present, and then I can add my guest to members:
Posted at https://sl.advdat.com/37Lfp4khttps://sl.advdat.com/37Lfp4k
