Gast-Nutzer sollen innerhalb einer SharePoint Online Website als Personen angezeigt werden. Und dies in dem Personen-Webpart oder auch im Header-Bereich einer einzelnen Seite im Autor Feld.
Info: Es ist zu beachten, dass Stand Februar 2024 in der People Card (dem Dialog der via Hover-Effekt angezeigt wird, wenn der Besucher mit dem Mauszeiger auf der Person stehen bleibt) außer der Mail-Adresse des Gasts keine weiteren Details angezeigt werden.
People bzw. Personen WebPart
Lösung:
Globale Aktivierung des Flags in der Tenant-Konfiguration von SPO mittels PowerShell als SharePoint Admin:
Die Home Site im Tenant wird beim Ausspielen von News-Artikeln an folgenden Stellen im SharePoint Online visuell hervorgehoben:
News-WebPart in Modern Pages
SharePoint App Bar -My News
SharePoint Start Page
SharePoint Mobile App – Tab „Neuigkeiten“
Es ist ein farbiger Block um den Namen der Website bei einer News-Meldung.
Ursache dafür ist eine Einstellung: die Organizational News Source Settings im SharePoint auf Tenant Ebene. Die als Home Site gesetzte Website wird automatisch auch als Organizational News Source gesetzt.
Zur Konfiguration gibt es nur einen Weg derzeit – die SharePoint Management Shell und der SharePoint Admin Rolle kann man mit folgendem Befehl sich die aktuellen Einstellungen ausgeben kann:
Get-SPOOrgNewsSite
Mit folgendem Befehl kann man die Home-Site auch deregistrieren:
Es gibt nur ein WebPart derzeit, der einem mehr Freiheiten gibt – der Markdown WebPart. Damit kann an den speziellen Hyperlink tel:// setzen
Leider wird diese Verlinkung in der mobilen Ansicht nicht korrekt ausgespielt so dass sie auf dem mobilen Endgerät zwar farbig als Hyperlink formatiert angezeigt werden aber nicht anklickbar ist.
Das Feature Hubsites in SharePoint Online gibt es seit dem Jahre 2018 und wurde damals in diesem Blog-Beitrag beschrieben. Es war lange nicht offiziell kommuniziert aber klar, dass es kommen würde: Hierarchien von Hub-Sites.
Bisher gab es nur eine einstufige Hierarchie – also eine Hubsite („Mutter“) mit einem oder mehreren „Kindern“. Nun gibt es eine zweistufige Hierarchie – also können die Kinder auch wiederum zu Müttern werden.
Nochmal mit anderen Worten: eine Hub-Website mit eigenem Hub A kann Mitglied in einem anderen Hub B werden.
Wichtig zu verstehen ist, dass sich nur wenige Dinge von dem oberen Hub auf untergeordnete Hubs vererben:
Vererbung des Such Scopes -> also eine Erweiterung des Such-Scopes
keine Vererbung des Brandings (Theme)
keine Vererbung der Berechtigungen
Nebenbei gibt es nun dynamische Navigationseinträge in der Website-Navigation für untergeordnete Hubs
Technische Umsetzung:
Laut meinen Recherchen ist die Zuordnung zu einem Hub in den jeweiligen Mitglieds-Websites (den „Kindern“) im Hub gespeichert. Eine Website kennt also die Website-ID der übergeordneten Hubwebsite – der „Mutter“. Die übergeordnete Hubwebsite weiß, dass sie die „Mutter“ ist, kennt aber ihre „Kinder“ selbst nicht. Sie weiß also auch nicht, dass eines ihrer Kinder auch wieder ein eigenen Hub hat und somit selbst „Mutter“ von weiteren Websites ist!
Mit folgendem Befehl kann man sich die Website-ID im Browser ausgeben lassen. Es ist eine GUID:
Mit folgendem Befehl kann man bei einer Hubswebsite im Browser die Property und die GUID finden, die alle „Kinder“-Websites im Hub ebenso gespeichert haben.
Mit der neuen Managed Property lassen sich also alle Kinder eines Hubs incl. der Mutter aus der Suche zaubern. Die Enkelkinder werden nicht zurückgeliefert da sie nur ihre eigene Mutter kennen 🙂
Limitierungen bei WebParts mit Aggregierung von Content im Hub
Es ist wichtig zu erwähnen, dass WebParts in SharePoint Online, die Content-Aggregation innerhalb eines Hubs anbieten für die Anzeige:
News WebPart -> News in einem Hub
Event WebPart -> Events in einem Hub
Website WebPart -> Websites in einem Hub
Highlighted Content WebPart -> Content in einem Hub
keine Funktionserweiterung erfahren haben – das bedeutet: die Aggregation von Content funktioniert nicht für Content aus untergeordneten Hubs! Sehr schade!
Fazit:
USP Nr 1: hierarchischer Search Scope – das ist eigentliche Grund eine solche Hierarchie anzulegen, da nun in der SharePoint Suche eine Breadcrumb-Navigation für den Anwender die Hub-Hierarchie anzeigt wird.
Es gibt zu viele Unzulänglichkeiten aus meiner Sicht: Eines ist, dass nur im SharePoint Admin Center das konfigurierbar durch SPO Admin Rolle ist. Der andere große Nachteil ist die fehlende Content Aggregation innerhalb der Hierarchie.
Das Hierarchie-Limit wurde von Microsoft festgesetzt und bestimmt in der nächsten Zeit nicht verändert. Der Grund ist auf jeden Fall keine technische Limitierung.
Die Navigation in einer Website des Intranets soll für die Intranet-Redakteure, die zwar Schreibrechte in der Website haben (um Inhalte zu redaktionieren) trotzdem schreibgeschützt sein. Das Warum ist klar: Ein versehentliches Ändern der Navigationshierarchie soll vermieden werden.
Lösung:
Die detaillierten Berechtigungs-Einstellungen in der Website aufrufen
Die Editor Gruppe auswählen und in der Symbolleiste „Change User Permission“ auswählen
In der darauffolgenden Seite im Abschnitt „Choose Permissions “ von „Edit“ auf „Contribute“ wechseln
Symbolleiste für die Bearbeitung von Gruppen Permission Level „Contribute“ auswählen
Ergebnis:
Der Bearbeiten-Button in der Navigationsleiste ist danach für die Redakteure ausgeblendet. Damit können die Redakteure die Navigation nicht mehr editieren.
MSTechnology 