See the below text from our document on how to set up the security ourselves
Whenever you create a Site Collection, two O365 groups get created (xxx-Owners and xxx-Members). For retro-compatibility, these O365 groups are automatically added to the SharePoint groups at creation time.
(Note for SharePoint gurus: O365-xxx-Members is mapped to SharePoint-xxx-members, but O365-xxx-Owners is mapped to… Site Collection Administrators! Crazy.)
SharePoint membership grants access to SharePoint resources, while access to Teams features (Channels, tabs, apps) is controlled directly via O365 groups.
The problem with this model is we cannot add AD (Active Directory) groups (or even O365 groups) within O365 groups (no nesting allowed). So, if we want to give access to two different sites to the same people (say SSWDevelopers), we must add ALL MEMBERS manually on EACH generated O365 group. That is ridiculous, and hard to maintain long term.
See the below screenshot – this is the default on the lists app. It shows all lists that I have permissions for and have added as a favourite list. Although it says ‘Home’ it shows not only lists in the ‘Home’ site but also any other lists that I have access to. These lists are not in the ‘Home’ site but are in other sites.
If I don’t know what the name of the list is that I am looking for how do I find it?
It would be better if I could see the hub-site navigation from the normal SharePoint site. That way I could just navigate to the SysAdmins site and see the lists in that site, or the Designers and see those lists. That would give more context.
In Teams when in video chat with only 1 other person and click Share Content | (there is no Whiteboard app)
When I add someone else to the call I can see the whiteboard app.
This is weird and wastes a lot of time debugging why this feature comes and goes. The button should always be there and if Microsoft don’t want to enable it for 2 people for some reason pop a message that says “Whiteboard is for 3 or more users”.
In SharePoint it shows the file history fine. But the history doesn’t completely appear in the Desktop/Web versions of Office.
We find ourselves looking at version history when debugging SharePoint stuff for clients, and it is useful. Until now we had never gone to Word to view the history – so to find out it does not work is concerning 🔥
In SharePoint we see:
In Web version of Word we see:
In Desktop versions of Word we see (Note we see more file history in the desktop version too):
The first Whiteboard app we released was a Windows (UWP) app on an Azure back end. This is still the form factor with the richest feature set.
We later added the web app (Web + Teams) which we are gradually evolving. The web canvas will eventually be the single canvas that powers all apps.
In parallel, we are moving the back end to ODSP (OneDrive/SharePoint). This is the right platform to handle the required scale, compliance, and sharing capabilities.
At the end of this transition period all clients (Teams, Web, Windows, iOS, Android, Surface Hub) will run on a single version of the web canvas to support collab scenarios across all devices.
That transition is complex because we need to build up capabilities on the web app to the level of the Windows client (and beyond), while transitioning the back end, and while also supporting cross-device collaboration sessions across different app versions (e.g. Windows and web) and back-ends.