For uploading and deploying SPFx packages I found these permissions to be the bare minimum:
Delegated Microsoft Graph User.Read
Delegated SharePoint AllSites.FullControl
Service Account
The second part is the service account that just has access to one site collection – Tenant App Catalog. That plus Delegated AllSites.FullControl of the app registration narrows the access to just that site. To install apps the Uploader Account needs to be Site Collection Administrator.
Least privileges for SPFx Upload & Deploy
Azure Pipelines
In our project we use Azure Pipelines where we also define the release using .yml. The deployment consists of series of bash inline scripts.
I am not going to describe all the steps for setting up node, npm and installing the office 365 cli. If you already have used Office 365 CLI with the default AAD APP it might look like this:
Now comes the tricky part! If you followed the guide mentioned above, you must have noticed the two environment variables that you need to have:
That’s straight forward when you run the cli in your own console. But the fact is (or at least from what I can see), you cannot “export” variables to other pipeline tasks.
Instead of setting the variables in the inline script, we can take advantage of the Bash task parameter called env:.
Some other findings:
Office 365 CLI needs them in all three commands: login, spo app add, and spo app deploy
If you create and export a variable in a pipeline task, it won’t persist, because every task starts a new shell session.
That means that we need to provide environment variables in every task in the pipeline, that uses Office 365 CLI with a custom Azure AD App. Or is there a better way? Anyway, the version below (the same tasks plus `env`) will work:
Eliminating Legacy Authentication
My goal is to remove the need of legacy authentication. Previously we installed spfx packages using PnP PowerShell. PnP PowerShell in Pipelines causes Legacy Authentication, it can be solved, though:
Honestly, Power Automate is great for automating repetetive stuff. But I think there is room for one-time flows as well. I’ll give you an example.
I’ve got an excel file with quite a few rows. And I need to convert it to a SharePoint List. I know there is a couple of options, such as Quick Edit in Classic View, Import an Excel file as a list (it also requires the classic view), there will be Excel import in Modern as well. But I need to also change the column names, maybe adjust something “on-the-go”.
If you had asked me to do that same thing one year ago, I would have created a script (powershell or javascript), loaded the rows and created all the list items.
But today, I find it much faster to set up a Power Automate (No worries, there is still need of “real” scripts and applications).
So my spreadsheet has two columns.
I create a new SharePoint List and adjust the columns to my needs.
After that I set up a very simple flow.
I could have loaded that excel, but I just pasted the rows directly in that flow. Hey, I will only run this once!
A positive side effect is that I also get a verification of the user accounts (my second column)
Since it run in an “Apply to each”, it keeps working even if specific rows fail.
These are my findings around Modern Sites without Office 365 Groups. It is, of course, a subject to change.
Today (2020-02-21) when you create a Modern Team Site without a group, you will get a site with the template STS#3. This oldie has been around for a while, hasn’t it?
I would always recommend creating Office 365 Group Connected sites.
How it is created
Through PowerShell/REST or from SharePoint Home, if your account is not allowed to create Office 365 Groups, it will automatically create a site without a group.
Site Creation Speed
It is really fast, much faster than the old STS#3, so something is different.
Custom Script
CustomScript is enabled. Which is the same as DenyAddAndCustomizePages=Disabled. CustomScript is a security risk, so I hope Microsoft will change that.
Groupifying
Yes, connecting to a new group is possible.
Listing Team Sites without Office 365 Groups
In SharePoint Admin you can filter them based on “Team Site (no Office 365 group)”
Want to translate your MS Forms into other languages? Create a form, not a quiz. It is available in both Forms and Forms Pro licenses.
Today I want to share one of my findings. One of those that seem obvious once you know, but that take time to find out.
Unfortunately, there is no official comparison of what is included in MS Forms vs. MS Forms Pro. So I thought that the ability to have forms in multiple languages was connected to the license.
It showed after many tests, that it is up to the type of form. The Form has the “Multilingual” feature. The Quiz does not have. Why? I don’t know. 🙂
Lesson learned: If you want to have your form in different languages, create a form, not a quiz in MS Forms.
One of the reasons why it is confusing is also the translation into Swedish.
Form – Formulär
Quiz – Frågeformulär. You can say “Quiz” in Swedish, too. Frågeformulär is very confusing.
English interface of MS FormsMulilingual only availalbe in a form, not a quiz
Sometimes all you need is just a simple static web page: instructions, a landing page, a collection of links. I think I have a perfect use case for Sway. Consider a scenario similar to what Laura Kokkarinen writes in her blog post:
An external user invitation needs an inviteRedirectUrl. Usually it is myapps.microsoft.com. In Laura’s case it was a given extranet url.
In our case we don’t know where an external user will land. After the invitation the external user will be added to some team or a collaboration site.
The default myapps.microsoft.com is a tool where a user can administer his account and accesses, but it might be a confusing place to be sent to after the invitation acceptance process.
A simple static page with clear information is just enough in our case. Fortunately, there is Sway, a simple (but still great) web page builder.
An example of a landing page, defined in Sway.
Following alternatives were considered for our landing page:
An “extranet” page in SharePoint Online. It takes time to set up if you don’t have an extranet.
A page in a public portal. Comms and IT must be involved.
A static web page in a blob storage / Azure CDN. It requires some basic web development for design and IT-driven deployment.
Azure App or Azure Function. Actually here it would mean going beyond static. For the initial phase, serving a static page, would also mean basic development and deployment by IT.
Advantages of a Sway page
Easy to create a static web page
Beautiful templates and an easy way to alter the design
Can be driven by the business/comms completely. We only need the url (to put into the invitation call to MS Graph).
Does not require any development or deployment.
Videos, documents can be embedded easily
A sway can be shared with anyone using the link. It means no additional infrastructure steps for this to work (such as firewall, dns etc).
There are some disadvantages, too:
The domain is too generic: sway.office.com. It might look suspicious to some users. Maybe there is a way to use own domain?
A Sway cannot have different languages and switch them based on the user’s locale. It would be great to have something similar to the “Multilingual” functionality in Forms. But still, as a static web page, Sway is doing great, even without the “Multilinguality”.
Summary
Sway is an easy “business friendly”, no-code solution for simple, still good-looking web pages, that can be created and updated in no time and shared easily. Being a member of the bigger Microsoft 365 ecosystem, it fills a certain gap where the business can work together with IT and deliver solutions faster.
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.
If you want to remove the Microsoft Teams Banner on your SharePoint Site, the only thing you need is to set a web property on a site: TeamifyHidden=TRUE. I’ll give you some guidance below. But before you do that, consider following:
If there is already a team created for a group connected site, the prompt won’t show up. Why fix something that is not a problem?
Only group owners will get the prompt, if they are few and they know what it is, it is better to let them to decide whether to create or not to create a team.
Only licensed users within your organization will be shown that choice. No external users or users without a license.
And the most important part: if any site owner selects “Don’t show me again” it will stop popping up for all other site owners. If you happen to have a manual step in the group creation process, then you can just click it away.
“Don’t show me again” option is per site, not per user.Internally, it is stored as a web property on root site of a site collection.
How to hide Teamify programmatically
Allright, if you still want to hide this prompt and you want to do it programmatically, you need to ensure that this web property is on every site collection root site.
Iterate through all sites
You can find a script for that on Microsoft Fasttrack github repository:
Performance and need for re-run. It iterates through all existing sites, meaning that it takes time to iterate through all of them and it requires that you run it again. In an organization with many new collaboration sites it might be a bad option.
Access to all sites. It requires SharePoint Admin, which is okay-ish, but it also requires that this admin account has access to all sites, in order to update the web property, which is not a good option when admins have a restricted access to actual sites due regulations.
CustomScript. CustomScript is disabled by default for a reason. Because it is a security risk. At least you should alter the script to reset the CustomScript setting on a site after you have changed the web property.
Hide Teamify site by site
You can of course hide the Teamify Prompt on a site without iterating. It is the same principle, but it doesn’t require iterating through all sites. You still need to be a SharePoint Administrator (or a Global Admin of course) in order to enable Custom Script. As in the case with all sites, you should reset the CustomScript to what it was.
Use GroupSiteManager Api
There is a new SharePoint Site API that you can call to hide a Teamify Prompt. All you need is to use the solution described in this sharepoint stackexchange answer:
This still requires that access to the site, but you will not need SharePoint Admin, nor will you need to change any CustomScript settings on a site. That’s better.
Calling PnP Rest Call to hide the Teamify Prompt.
Summary
There are ways of hiding the Teamify Prompt on a site collection. If you do that you should include that step in some provisioning process, and not iterate through all sites. It is better to not alter the CustomScript settings at all. First of all it is best to ask yourself why you should disable something that is done for users and for a better user adoption. Also consider that usually only few will be shown that (group owners with a license and within the organization). The group owners can also hide it by clicking “Don’t show me again” and it will disappear for all other group owners.
First, enable a Managed Identity for your Logic App:
In the KeyVault, add a new Access Policy for the new Managed Identity (from the previous step). Use the least priviliges. In my case it is just enough with GET for secrets.
Instead of filtering values from an Azure Storage Table, you can do it directly in the bindings. It might not be a solution for everything, but in the right place, it is fantastic. I was very surprised to see how little code was needed after this binding change:
For that to work, define the filter attribute in the bindings: “filter”: “(PartitionKey eq ‘{package}’)”
To try it out, add a new row in a table defined in the bindings (“metadata” in my case):
Start the function app and navigate to your function:
Just a quick tip today. I hope this helps you in your work. The raw material comes from stackoverflow:
Recent Comments