Warning - Modern Pages on Existing (None Microsoft Teams) SharePoint sites - Lots of things broken

[Andrew Silcock]

Hi all,

I've been creating New Site Pages on standard SharePoint sites in order to utilise the Modern pages on our Sites.

Everyday at the moment I am discovering more and more issues with using pages like this and I'm incredibly surprised Microsoft have made it possible to create these modern pages on existing (None Microsoft Teams) SharePoint sites without testing any of this out. Clearly these pages have only been tested to work with SharePoint sites created via Microsoft Teams:

The most concerning one is:

1 - On Modern pages the Site permissions side menu (After clicking Cog > Site Permissions) doesn't reflect permissions against groups. I.e. The permission levels mentioned only reflect what was initially setup when the site was created. For example - If I change the Site Visitors Permissions group to have Full control access under site permissions, in the fancy new side bar menu it still says I am giving the user Read only access. This side bar has clearly only been tested on SharePoint Sites created through Microsoft Teams.

There has also been the following:

2 - Modern Highlighted content web part on Modern page not working unless user has at least minimum access to root site collection site. (Nothing can be done about this one)
3 - Modern Highlighted Contents web part on Modern page - Show this many items at a time property not being read, number of items remained the same. (Fixed)
4 - On a modern site page or modern document library, as a Site Owner (With Full control permissions) I click: Cog > Site Permissions. I get access denied. (Still ongoing)
5 - The "New" drop down is available on a modern site page, allowing users to initiate the creation of a new page despite users only having read access to the pages library. (Still ongoing).
6 - Modern Hightlighted contents web part on Modern page - Currently not working on multiple sites on multiple site collections. (Still ongoing).

This is a heads up for anyone considering using them at the moment.

[#2]

@Dan Holme FYI

[#3]

Adding some folks @Sohail Tariq, @Alyssa Danesh, @John Sanders

[#4]

Hi all,

Just an update on the misleading Site permissions side menu issue.  I logged a ticket with Microsoft support essentially turning this one away:

"We received the rejection from Microsoft product team on this ticket. They refused to change the permission behavior on the site page. Their original intention of the design on those groups [Owner/Member/Visitor] should have corresponding permissions [Full control/Edit/Read]. They don’t want the customer to change those groups’ permissions. Since those groups are created by SharePoint online system automatically, the product team hope the customer can use those groups normative as they hope."

I'm going to get back them about this one because I don't think the potential seriousness of this one has been thought about nor just how widespread this is.

Some more details regarding this one:

The issue occurs on all SharePoint sites (expect those automatically created via Microsoft Teams).  As a site owner I am able to click the settings cog in the top right and then Site Permissions.  This option is available from all “modern” style pages and apps in SharePoint, including modern pages, document librarys and the Site Contents page.  The information displayed here is not representative of the permission groups and levels available on the site, unless you have made absolutely no changes to the default groups and levels applied to those groups.  Which isn’t the case on any of our sites (200+) and I imagine the case in many SharePoint sites out there in the world.

What looks like a permissions level you are applying against a user is in fact some kind of default name given to the group, which we can’t change.  For example, on my test site there’s a Permissions group called “New Team Site Visitors” no matter if I give this group read, contribute or alarmingly full control, the drop down still displays read and when I choose to give someone the Read permissions they are put into the “New Team Site Visitors” group granting them whatever permissions level that is assigned to that group.

It is clear this new Site Permissions nenu bar option has been designed to work exclusively with SharePoint sites created through Microsoft Teams.  It definitely shouldn’t have been rolled out worldwide.  This site permissions option is the most obvious place to go to for owners to modify permissions and therefore this is going to cause potentially serious consequences. 

[#5]

Do you have specifics you can share on #6?

I'm not sure what you mean by "6 - Modern Hightlighted contents web part on Modern page - Currently not working on multiple sites on multiple site collections. (Still ongoing)."

Thanks,

John

[#6]

Hi John,

Yes, #6 has now been resolved. It turns out you need at least limited access to the site collection site in order for the highlighted contents web part to work on the sub sites below that site collection.

[#7]

Hi John,

Are you able to supply any details on this one?  According to Microsoft support "I have got the confirmation from PG that this is by design", which is both surprising and concerning.  

We have hundreds of sites that have the Site Permissions options from the cog which is displaying incorrect permission levels with potentially dangerous consequences.

Thanks,

Andy.

[#8]

Hi John,

I've discovered another issue with the modern pages used on standard SharePoint sites.

When a site owner clicks “New > App” from a sub site home page. It takes me to the add an app page for the site collection this sub site is under.

This is again, functionality design for SharePoint sites created via groups/planner/Microsoft Teams (i.e. designed to work on the top level of a site collection) that has been moved across to standard SharePoint sites but not tested correctly.

[#9]

I agree totally with Number 5 in your list - the New button fakes read only users out by letting them get to the Name Your Page screen.

To make matters worse...the error that read only users get is ridiculous. It says the error is "unexpected" well...what was unexpected was the fact that a read only user even saw the add new page button in the first place.

This all resulted in me having to rebuild 2 new pages with the old wikis

[#10]

Hi Michael,

I logged a support ticket and the latest I heard is "Product team has now finding the root cause of this issue from code level and re-directing it to the correct team who owns the feature. Hopefully the fix won’t be too long. ".

[#11]

Here is something I noticed in testing. 

• Create new classic site collection
• Grant "everyone except external users" access to the "members" group (Contribute permission level)
• Create new modern site page
  • All users have ability to add a new page (+new button) as expected 
• Edit top level permissions for "members" group to "Read"
  • Now all users have only read access to the page
  • +New button does NOT show on site page (expected behavior)
• Access permissions for "Site Pages" and break inheritance
  • Edit unique permissions for site pages by changing the members group to "Read"
• Result is that users now see the +New button and get an unexpected error when they use the button and try to save the page.

[#12]

My biggest issue with this is the new News app. I dislike it to the point of wanting to have a serious discussion with the 12 year old that designed it. The interface is awful for standard users. The old team app bought them a familiar interface using the MS Word ribbon. Now they need to understand building pages, not adding in news. The training and support required means we just cannot role this out. Our concepts are anyone can post a new item.

Now add to that the fact that it is pages you are creating, so what permissions are needed, design as a minimum. So we build a great site and then one of the people that is meant to only be adding a news item clicks edit and wonders what all of there funny things are doing on their news item and delete them all.

Very poorly thought through and I hope they never never never repeat ad infinitum) make this the only available option. We need to keep the old news app that worked well for staff that are creating news items.

[#13]

Hi Mark,

It works for us because the users adding news are also the users who are administrating the pages. Also, a lot more can be achieved on a page than a classic news text box.

If training is a concern, you could perhaps just show users how to add/edit a modern text web part on the page? Separating the articles with a line?

Unfortunately, I do not think there is anything you can do with the permissions issue you mentioned, it's ok for us, but I can see it being an issue for others. If the news pages were located in a folder in the site pages library, that would allow separate permissions to be set between the news articles and the site pages.

[#14]

Thanks Simon, but I always sell SharePoint as a great communication tool for users that have little to no technical skills. And some small organisations are loving the ability to use this to share ideas and concepts across the team. But there is no way we could let them lose on the new team sites until the security features take into account the end user communities.