Jag förstår att det är väldigt mycket kod för att få till kalendervyn och att det inte är så lätt omvandla till ett modernt utseende, men det ställer till eftersom det upplevs som gammalt och inte användarvänligt ute i verksamheten.
Varför behövs en SharePoint-kalender
Jag ska lista några alternativ och förklara varför en gammal dinosaurie är fortfarande det enda vettiga alternativet (i väntan på en “modernisering” av lsitan)
En Office-365-gruppkalender
Det är en bra funktionalitet för en enkel kalender. Den saknar:
Stöd för extra kolumner och innehållstyper
Den är svår att dela med externa användare
Händelser (Events)
Om du inte hittar länken till den här sidan, finns den under <site>/_layouts/15/Events.aspx. En snygg modern sida som kan visa kalenderhändelser från flera kalendrar på SharePoint-siten. Dess begränsningar är:
Går inte att anpassa, eftersom det är en systemsida (layous-sida)
Den visar bara det minimala om händelser
En kalender utanför Office 365
Har man egen kalenderdata, är man friare, men man förlorar fördelarna med att ha/betala för en dyr platform. Om man också har ett eget gränssnitt för det kostar det att i längden med alla anpassningar och buggrättningar.
SPFx-lösning
I SharePoint skulle man kunna ha en SPFx-lösning för att presentera kalenderdata på ett snyggt sätt. Men det får avvägas mot kostnader. Det fina med inbyggda kalendern var att den bara fanns där, den ingick i plattformen.
Kalendern i SharePoint
Till fördelarna av kalendern i SharePoint hör:
Det är en del av ett större ekosystem. Power Automate eller PowerApps kan kopplas på, som ett exempel. Det visas också i moderna Events.aspx
Det är anpassningsbart på ett enhetligt sätt, som alla andra listor. Användare med rätt behörighet kan skapa nya kolumner, definiera innehållstyper med mera.
PnP-mallramverket kan både exportera och importera en kalender.
Listvyer, behörigheter, mappar, allt det ingår om man behöver det, på samma sätt som det gör för alla andra listor i SharePoint.
Möjlighet till sök och aggregering ifrån flera siter.
En chans att det moderniseras utan att man behöver investera något i det extra.
En förenklad vy genom “Händelser” av samma kalenderlista.
Lite tips och tricks för gamla kalendern
Här kommer en liten samling av enkla men intressanta tips för gamla kalendern.
#1 Välj tid för en ny händelse med en annan innehållstyp på ett smidigt sätt
Det här har varit en av de sakerna som man varit mest frustrerad över. När en kalender har flera innehållstyper, går det inte att byta innehållstyp i NewForm när du klickar i kalendervyn.
Om du väljer en annan innehållstyp, måste du manuellt ange tiden. Det tar tid. Föreslagna tiden är bara aktuella timmen här och nu.
Tipset är att:
Hitta rätt dag och markera rätt tid i kalendervyn. Rutan får en blåaktig färg.
Klicka på “Ny händelse” i Ribbon (vad var svenska namnet för det?).
Vips så har du tid och datum rätt ifrån början
#2 Kalenderöverlag
En klassiker, en av mina favoriter är möjligheten att visa kalenderhändelser med olika färger – kalenderöverlag. Tyvärr är det begränsat med färger.
#3 Visa veckovyn utan att ändra inställningar
I länken till din kalender (t.ex. i vänstermenyn), lägg till “?calendarperiod=week” i URL:en, så visas veckovyn automatiskt.
I saw a demo of it on the European SharePoint Conference in Copenhagen in 2018. Sebastian Fouillade, who showed this, compared this big change with brain surgery. All the urls, all the connections. But now it is possible. Today I have seen it even in my standard release tenant.
It is really appreciated. Soon it will be possible to rename misspelled sites, like “devlepment” to “development” etc.
To rename you need to go the SharePoint Admin, find your site among Active sites and click on “Edit” in the site url area.
I also can image, it will be very handy to change the url of a SharePoint site that was automatically created for a Team (through the Office 365 Group). The team might have some longer name, but a simpler url is often appreciated.
I have tried and seen that also the automatic redirects from an old site url to a new site url works.
Caveats and Limitations
mailNickname ≠ site url
Now it is even more important to not to rely on the fact that mailNickname of an Office 365 Group and Site url are the same. As Elio Struyf describes, it is not a good idea to compose a URL from the group name. I have used in PoCs the site url to get the group id:
Now it the amount of cases where it will work, will be less.
Not all site types can change url
I have found that the App Catalog site cannot get a new url, neither sites with Publishing Features.
The official message from Microsoft
We’re making it possible for SharePoint administrators to change site URLs.
We’ll be gradually rolling this out to customers in mid-October.
The roll out will be completed worldwide by the end of October.
This roll out does not apply to Office 365 subscriptions for EDU tenants.
This message is associated with Microsoft 365 Roadmap ID 56205.How does this affect me?
As a global or SharePoint admin in your organization, you will be able to change the URL for the following types of sites (previously called “site collections”):
Classic team sites
Communication sites
Modern team sites that don’t belong to an Office 365 group
Office 365 group-connected team sites
For example, if you have a site named https://contoso.sharepoint.com/sites/Develpment, you can rename the site to correct the incorrect spelling of “development” via the SharePoint admin center.
Automatically-generated redirects will ensure that old links do not break.What do I need to do to prepare for this change?
There is nothing you need to do to prepare for this change, but you may consider updating your user training and notifying your help desk.
Have you more than two (jquery and jquery-ui), then you have too much. You can save much place and performance by using Content Delivery Network (CDN) links for the resources like javascript, css, fonts and icons. Consider those Content Delivery Networks:
But can we benefit from this CDN concept for our custom resources? I think so, if your farm has ten thousands of site collections, and you deploy javascript files, css files in the Style Library, it would be great to eliminate resource duplicates. So my thougt is to deploy resources to one place. It could be:
Recent Comments