First published on MSDN on Apr 20, 2018
This one should only affect administrators, but the behavior will also help explain why other users may not see the New plan option. So what does this look like? When Planner loads initially as it loads the New plan option can be seen – just above the Planner Hub option:
But as the page finishes loading a few calls will have been made to check tenant settings and group memberships – and the UI will be trimmed and New plan option removed:
This was a recent change due the the work we are doing in Planner to support Guest access – and we are trimming the UI so that people who are not allowed to create Groups do not see the New plan option in Planner. The article at https://support.office.com/en-us/article/manage-who-can-create-office-365-groups-4c46c8cb-17d0-44b5-9776-005fced8e618 explains how to control Group creation and whether Guests can create groups too. To control other users you can set a setting at the tenant level – EnableGroupCreation = False, and then create a security group populated by all the users who you are allowing to create Groups. The GUID for this group is set against the property GroupCreationAllowedGroupId.
Where this comes unstuck is if you have configured this option but have not included the admins in the group allowed to create Groups. Admins bypass this control and can always create Groups – but our checks don’t find them in the group and trim the UI. In Planner there is no way to determine if the current user is an admin.
A couple of workarounds – firstly if you are quick then you can click on New plan before it goes away and you will be able to create a plan (admins only – if the UI is being trimmed because you can’t create Groups then you will still not be able to create Groups. The better solution is to add all of your admins to the group you are using to control group creation – then they will not get trimmed UI.
For the inquisitive amongst you take a look at the F12 Developer tools in your browser of choice and you can see the calls that are getting the data to make the trimming decision.
GetCurrentTenantSettings returns the settings to know if how EnableGroupCreation is set (False in this case) and also the group used to control who can create Groups (0ff9c27d-47f3-4d19-b39a-695c8e8ae9d1
Once we have this GroupId we can check if I cam a member using CheckCurrentUserToGroupMemberships – passing in the GroupId. This will return an array of the Groups that were passed in of which I am a member (This time there was only one group – but the same call can be used to test many groups)
The empty array ([]) confirms that I am not a member so the UI gets trimmed!
This one should only affect administrators, but the behavior will also help explain why other users may not see the New plan option. So what does this look like? When Planner loads initially as it loads the New plan option can be seen – just above the Planner Hub option:
But as the page finishes loading a few calls will have been made to check tenant settings and group memberships – and the UI will be trimmed and New plan option removed:
This was a recent change due the the work we are doing in Planner to support Guest access – and we are trimming the UI so that people who are not allowed to create Groups do not see the New plan option in Planner. The article at https://support.office.com/en-us/article/manage-who-can-create-office-365-groups-4c46c8cb-17d0-44b5-9776-005fced8e618 explains how to control Group creation and whether Guests can create groups too. To control other users you can set a setting at the tenant level – EnableGroupCreation = False, and then create a security group populated by all the users who you are allowing to create Groups. The GUID for this group is set against the property GroupCreationAllowedGroupId.
Where this comes unstuck is if you have configured this option but have not included the admins in the group allowed to create Groups. Admins bypass this control and can always create Groups – but our checks don’t find them in the group and trim the UI. In Planner there is no way to determine if the current user is an admin.
A couple of workarounds – firstly if you are quick then you can click on New plan before it goes away and you will be able to create a plan (admins only – if the UI is being trimmed because you can’t create Groups then you will still not be able to create Groups. The better solution is to add all of your admins to the group you are using to control group creation – then they will not get trimmed UI.
For the inquisitive amongst you take a look at the F12 Developer tools in your browser of choice and you can see the calls that are getting the data to make the trimming decision.
GetCurrentTenantSettings returns the settings to know if how EnableGroupCreation is set (False in this case) and also the group used to control who can create Groups (0ff9c27d-47f3-4d19-b39a-695c8e8ae9d1
{"AllowGuestsToAccessGroups":true,"AllowGuestsToBeGroupOwner":false,"AllowToAddGuests":true,"ClassificationDescriptions":[],"ClassificationList":["Low","Medium","High"],"CustomBlockedWordsList":[],"DefaultClassification":"","EnableGroupCreation":false,"EnableMSStandardBlockedWords":false,"GroupCreationAllowedGroupId":"0ff9c27d-47f3-4d19-b39a-695c8e8ae9d1","GuestUsageGuidelinesUrl":"","PrefixSuffixNamingRequirement":"","UsageGuidelinesUrl":”Http://aka.ms/o365g”}
Once we have this GroupId we can check if I cam a member using CheckCurrentUserToGroupMemberships – passing in the GroupId. This will return an array of the Groups that were passed in of which I am a member (This time there was only one group – but the same call can be used to test many groups)
"{\"@odata.context\":\" https://graph.microsoft.com/beta/ $metadata#Collection(Edm.String)\",\"value\":[]}"
The empty array ([]) confirms that I am not a member so the UI gets trimmed!
Published Mar 06, 2019
Version 1.0
