Monday, February 6, 2017

Gaps and differences between a Group 365 Modern Team Site and a plain old Team Site

This post outlines some of the differences between an Office 365 Group Modern Team Site and a plain old SharePoint Team Site as of February 7th 2017.

[Updated to match the GA announcement February 23rd 2017]

The gaps may or may not affect you, but from a document management perspective we keep hitting several of the differences in every single projects which often leads to falling back to a plain old Team Site.

As there has been talks of enrolling/upgrading plain old Team Sites into a modern site in a group, I hope the limitations will go away and align more in the future. At Puzzlepart we see the most important ones being able to programmatically configure up pages in a scalable way and having access to synchronized content types.

image
Functionality Modern Team Site SharePoint Team Site Comment
Modern lists Yes Yes Works in both types of site.
Modern libraries Yes Yes Works in both types of site.
Modern pages Yes Yes Works in both types of sites, but the modern team site has a different landing page not available in the old team site.
Embed maps/videos etc. Yes(*) Yes For modern team sites you can only embed from the default white listed domains (YouTube, Vimeo, Office, Microsoft, Bing, Live, PowerBI, Sway, Docs, Stream), so no Google maps.
Top navigation No Yes Modern team sites only have the Group navigation and entries to subsites (don't do it!), and no options today for custom links.
Content Types Yes Yes You can create custom columns and content types in both types of sites.
Content Type HUB synchronization Yes Yes Allows easy distribution of content types and columns to all sites.
Membership customization You can customize any level of security You can customize any level of security Modern team sites have owners, and members from an AAD group. The AAD group can be given any rights you want. Public groups also have Everyone as contributor by default, these can now be given visitor access. Besides this, you can add people at any level you want, but this only yields for the team site, not other group assets like Planner.
Upload aspx files No Yes This is needed if you want to configure the site programmatically upon creation to suit your business needs. For example have a customized modern page as the landing page, or add other information pages upon creation.
SPFx web parts Yes Yes Being rolled out to everyone right now
Custom actions Yes(*) Yes Modern team sites only support this via the App model, not direct custom actions. Custom actions do no work on modern pages.
Script embed No Yes For modern team sites you can create a custom SPFx web part to support this.
Site property bag support No Yes You cannot programmatically update the site property bag on a modern site, but in many cases you can work around this. This has traditionally been used to store site meta data.

Also take a look at the support article Differences between classic and new experiences for lists and document libraries for what works and not in modern views.

Update 2017-02-14
I had someone ping me on Twitter saying you can do granular view/edit permissions going directly to _layouts/15/user.aspx on a modern team site and I know that's a possibility. Or do it programatically.

However, I think this is a bad bad bad bad bad idea. If you're a member of a group you are either in or out, and can work with all services in the Office 365 Group. Seeing the Group team site isolated does not make sense to me, and I tend to get really worked up in discussions around this (as happened this morning). If Office 365 Groups roll out a complete visitor/member option, then I'm all for it. For now I would go with what is visible directly in the UI - or use STS#0.

Update 2017-02-28
Microsoft decided to put a link to the user.aspx in the UI. Which means you can easily add/remove other AAD groups or people at will - like you did on a classic team site. You can however not split up the members from the Office 365 groups AAD group at will. That AAD group has to be given equal permissions. Of course, you can lower it, and give certain members more rights.

All of this reminds me when I taught power user courses for SharePoint 2010 - permissions gets muddy and complex pretty quick, with no control. Keep it as simple as you can, and you will slee better at night and support will love you. If you ever have a chance to chat me up at some event I'd be more than happy to discuss permissions around sites and groups :)

12 comments:

  1. I was playing around with groups recently and noticed that the user that created the group has full control on the site but the user is not visible in the Owners group in the team site. "Check permissions" for that user revealed that the user IS actually a part of Owners group :)

    https://techcommunity.microsoft.com/t5/Office-365-Groups/Best-Practices-for-Permissions-on-an-O365-Group-SharePoint-Site/m-p/30220#M1265

    ReplyDelete
  2. Hi Mikeal,
    The property bag restriction thing is really disappointing. You said "..in many cases you can work around this." Can you elaborate on what this work around is, or does it boil down to "solve your problem without using property bag"?

    ReplyDelete
    Replies
    1. Correct, you need to figure out other ways. For example a list.

      Delete
  3. Hi,
    I am not sure what you mean by "You cannot programmatically update the site property bag on a modern site". I created a set of webparts to manage the property bag on the sites rootweb and build navigational element from those properties. See https://github.com/russgove/sp-dev-fx-webparts/tree/dev/samples/react-property-bag-editor
    The solution has been submitted to sp-dev-fx-webparts.

    ReplyDelete
    Replies
    1. Interesting, I've been blocked on all Group sites when I tried last when trying to set property bag values on the web. I'll retry it tomorrow for sure. So far no-script sites have blocked this.

      Delete
    2. Tried just now.
      $web.AllProperties["foo"] = 1
      $web.Update()
      $web.Context.ExecuteQuery()

      ..and I get access denied. Both with SP admin account and app tokens. On a regular team site it works fine.

      Delete
    3. But you can use the property bag of a list or library. Maybe not the coolest work-around but can be ok in some scenarios... On some projects I use the property bag of the default doc lib instead.

      Delete
    4. And you can actually use the web property bag if you enable scripting on the site.

      Delete
    5. And how can you enable scripting on a modern team site?

      Delete
    6. I have some PnP powershell on this post down in the article which shows how: http://www.techmikael.com/2017/05/three-reasons-why-you-should-take.html

      Delete
  4. Ah, Disregard my previous comment. I am only working with Teamsites that have the modern UI. Not O365 Groups.

    ReplyDelete
  5. Hi, You were correct. The sites I was working with had the modern UI but were not truly Modern sites. just teamsites with the modern UI.

    ReplyDelete