Wictor Wilén is a Group Manager and SharePoint Architect working at Avanade. Wictor has achieved the Microsoft Certified Architect (MCA) - SharePoint 2010, Microsoft Certified Solutions Master (MCSM) - SharePoint and Microsoft Certified Master (MCM) - SharePoint 2010 certifications. He has also been awarded Microsoft Most Valuable Professional (MVP) since 2010.
Happy Easter everyone, I have fantastic news. After seven preview versions (and even a skipped version - 2.6) the Microsoft Teams Apps Yeoman generator 2.7.0 is now available for you to use! Just like tons of others do; there's been over 6.000 downloads of the generator, it's generating a handful of new Teams projects every day and it's done from all parts of the world! Join the movement!
As usual it is just a simple npm command to install:
npm install generator-teams --global
Version 2.7.0 contains quite a few updates, changes, additions and fixes. For all the details please study the CHANGELOG. But here is a summary of the more important updates.
Support for Microsoft Bot Framework 4 - this is one of the more substantial changes. The default scaffolded bot looks very different, using the new Bot Framework 4 and the sample bot created contains some examples for you to build on. Note that the middleware for Microsoft Teams is still in beta. Message Extensions middleware - as the time of publishing this there's no support in the Microsoft Teams Bot middleware for message extensions and to make the code easier to read and extend a dedicated middleware is used to manage message extensions. This middleware is available as a standalone npm package. The automatic configuring of the Message Extensions are handled by the express-msteams-host package, and see it's documentation for all the details. Microsoft Teams schema 1.3 - the default schema is now 1.3, but also the devPreview schema is supported for validation. Restructuring of artefacts - from this version and forward each artefact will be scaffolded into its own folder in order to make them easier to manage and find in a larger Microsoft Teams Apps project. Dynamic generation of the manifest - the manifest file created by the generator will now have placeholders for things such as the host name, bot id's and connector id's and more. The value of these placeholders are either defined in the .env file or in the application settings and will be replaced when building; gulp build, gulp serve or in the case of the manifest gulp manifest. Improved generated code - all code is now properly linted and linting support is also added to the generated project. This also resulted in that the default casing of files and class names has changed to support the linting. Test support - when scaffolding a project you now have the option of specifying to include test framework and sample tests (for now only Tabs) using Jest and Enzyme. Huge thanks to Çağdaş Davulcu for helping out with this task. Bug fixes - yes, we found a few bugs and squashed them!
What about updating?
Since this is a generator, it generates the skeleton code for your Teams Apps, there's no way to upgrade an already scaffolded project using the generator. If you want the latest and greatest, you should create a new project. Then migrate over your existing customizations. Remember to copy over the application id from your old manifest to the new one.
All very nice updates and new features! And now we're looking forward and are already planning the next version! What do you want to see?
I’m excited to be returning to Las Vegas in May of 2019 to speak at the SharePoint Conference 2019 in May 21st to 21rd, at the MGM Grand.
This event is one of the two major events, second one being Microsoft Ignite, that the SharePoint, OneDrive and Yammer product groups are announcing their greatest and latest features and also where you will meet some of the finest speakers and community members of our great SharePoint family.
There will be over 200 session giving you all things you need to adopt, build and manage SharePoint Online and if that is not enough there’s even three days of Workshops, more than 20 of them, with even more deep dives into SharePoint, PowerBI, PowerApps, OneDrive – delivered by amazing speakers.
Full Page Apps in SharPoint Online
This session will cover all the different options we have of creating these full page experiences in SharePoint Online, using SharePoint Framework Web Parts, zones and page designs. We will of course, if you know me, spend most of the time looking at the code, but also discuss different strategies on when to use which method. And last but not least, given the announcements on how SharePoint Framework and Microsoft Teams can be used together, this will be a topic that we’ll cover.
It’s been a few years since I presented at the SharePoint conferenes, and it’s always been a blas, remembering one session where we spent an additional 90 minutes of QnA. Bring all of your questions you have on this topic (and of course anything else you think I or other speakers can help with) and get your answers – there’s no better way for you to get value from this conference than getting answers to your questions.
There is still a few more months to go until May and I’m looking forward to be able to modify the session to incorparate all the latest and greatest features in this area. We’re living in an Evergreen world so this session will be as fresh as possible when delivered – so you have to be there! For the latest updates on the sessions content you can always go to the session page at the SPC19 site: https://sharepointna.com/#!/session/Build%20Full%20Page%20Experiences%20in%20SharePoint%20Online
(I know it is currently tagged as an IT-Pro, we’ll fix that, so we can make fun of the IT-pros for realz during the session)
Register and save $50
Talking of being there, if you have yet not signed up for the conference, you should do it right now. And I can save you $50, that you can spend on gifts to your family for the holidays seasons coming up. Go to https://askwictor.com/SPC19 to register with my discount code WILEN (my awesome last name in all caps – and extra bonus for a correct pronounciation) and you will get a $50 discount. And even better, if you do it before the 15th of January you will get an XBox, a Surface Go or other cool stuff depending on your selected package.
I hope to see you there, in my session! Happy holidays from Sweden, where the snow now has started to fall!
Imagine you want to create a chat bot for Microsoft Teams in order to automate tasks, enhance the discussion or just feeling lonely and want someone to talk to. There’s many ways of doing this; you can start from scratch building a bot, using the Microsoft Bot framework and/or using the Microsoft Teams Yeoman generator, you can use the Azure Bot Service, you can use the FAQ bots to essentially create a no code solution.
But, what if you need some logic to happen with your bot, what if you’re not that adverse in coding or have all the skills to build something using Microsoft Cognitive Services, such as language understanding and what not. What if you could use Microsoft Flow to automate tasks, initiated from a conversation in Microsoft Teams?
Then this is your lucky day, you can do this almost without any code (more on why a little bit later) and be up and running within minutes – and also without involvement of any admins that needs to approve of your solution!
First of all we need a Microsoft Flow to do the stuff we want to do. In this sample I’ll create a bot that I can use in a Teams discussion to create a task in my Microsoft To-Do task lists. The Flow is very simple and consists of one HTTP trigger (When a HTTP Request is recieved) and then a task that add a task to To-Do.
You should copy and store the URL, generated in the HTTP trigger upon save, as we will need that for our bot in just a minute.
For now the Subject is static, but for the Body Content I use the text property of the incoming JSON – that will be sent from the Microsoft Teams client. I use the Dynamic Expression to get text from the Teams message:
NOTE: If you want more help with what properties you can use, such as creating a link to the original message, you can use the HTTP trigger and import a sample paylod found in the Microsoft Teams documentation. However currently that page is not up to date with the latest schema, so the best way is to make sure this sample works, and then just take a look at the Flow history and copy-paste the JSON from a successful run.
Creating the Microsoft Teams bot
To create the bot in Microsoft Teams we take advantage of the feature called Outgoing webhook. This is a somple way that allows you to send an outgoing message when at-mentioning the bot in a Microsoft Teams team (there’s no personal equivalent at the moment). You can add a new outgoing webhook by going in to the Team settings and then click on the Apps tab. In the lower right corner you will find the link called “Create an outgoing webhook”. Click on that one to create it.
In the dialog that appears you need to fill in the name and description of your outgoing webhook (bot) and optionally upload an icon. What you also need to do is to add the Callback URL. Let’s add our URL generated for the MIcrosoft Flow and give it a shot.
When you click on create, you will get another popup with some vital information. It contains a security token, used for validating the message. This is the only time you will see it and if you forget it you have to create a new outgoing webhook. So copy-paste this into a notebook or remember it, you will need it shortly.
Let’s try this
So, now we should be able to chat to our outgoing webhook/bot by at-mentioning it in a channel in the Team where we added it.
Hmm, that was not what we expected, and this is where a lot of people have stopped trying this approach. It’s not that unexepcted though. Remember I just said the outgoing webhook has a security token, that we should validate, and also the Microsoft Flow does not send any message (JSON) back.
Azure Functions to the rescue
In order to get this to work, we need to smack some code up in sort of a proxy, that will sit between the outgoing webhook and the Microsoft Flow. The easiest and probably cheapest way is to use Azure Functions. So let’s do that.
In this Azure Function we can now write some code that
On line 4 you need to add your Security/HMAC token generated when you created the outgoing webhook
On line 5 you need to add the webhook URL for your Microsoft Flow
Since this example uses the request npm module, which is not by default installed in an Azure Function you need to go in to the Console located at the bottom of the Azure Function code editor and run
npm install request --save
Note: for production and real scenarios you might not want to build your Azure function directly in the Web UI and you should have a package.json file so any npm modules are properly restored.
Then, just save the Azure function and go back to Microsoft Teams and the same location where you created your outgoing webhook. Click on the outgoing webhook you created to edit it and then change the URL to the Azure Function URL (found next to the Save and Run buttons in the Azure Function code editor - Get function URL).
Let’s try it again
Head on back over to Microsoft Teams and into a channel, now try to at-mention the bot again!
Look at that! It’s working. I can even go over to To-Do and see that I have a new task!
This was the basics on how to get things working. You can of course make the bot far more advanced by injecting more logic to the Microsoft Flow (obviously) but also into the Azure Function. For instance you might want to invoke different flows, depending on the message. You have full access to the JSON in the Azure Function to do this.
One caveat is that right now you only have access to the message where the bot was at-mentioned. Hopefully Microsoft Flow gets some more Microsoft Teams features so we can extract the full conversation. Meanwhile you can always use the Microsoft Graph, but that involves a few extra steps for app permissions etc.
This approach has already today saved me and my team from having to manually do some steps in our daily routing, by simply at-mentioning a bot in our conversation. What cool stuff are you building with this?
A long overdue update of the Microsoft Teams Apps Yeoman generator – we’re now up to version 2.5.0! It’s a fairly substantial update both in the generator and in the generated code – this update will make future updates a lot smoother and will allow for enabling more features going forward. Thanks to all who provided feedback and input and has tested the generator over the last few months.
You can get the latest generator by running
npm install generator-teams@latest –global
The actual Yeoman generator has been refactored and changed so that it used TypeScript AST (abstract syntax tree) to dynamically generate some of the TypeScript files. This will open up for adding new artifacts to existing projects without having to do weird string and text file parsing. We’ve also refactored some generated files out to separate npm packages, so that those files and controls can be updated without you having to manually update files or generate new solutions – more about this below.
In order to improve the generated app we have moved some of the generated files, controls and base classes into separate npm packages. This allows you to get the latest and greatest in these packages with just a simple npm command – and not having to manually copy and paste.
The generated solution is hosted in a node.js Express server and the new generated solutions will dynamically discover what components and extensions you have in your solution and automatically register the different routes. All this is done by using TypeScript decorators and Express routes that are defined in the express-msteams-host npm package. Previous versions of the generator had a quite complex server implementation and since it was scaffolded by the generator it was close to impossible to update with new features or fixes. Now all you have to do is decorate your bots, connectors and outgoing webhooks with these decorators and their routes will automatically be picked up and registered. For more information, see the documentation.
A similar approach has been taken to the clients side of the generated solution. A few releases ago the UX was moved to leverage the Microsoft Teams React controls, and with this version we’ve moved the base page class (previously generated by the generator) into a separate npm package called msteams-react-base-component. Similar story here, this will make it way easier for everyone to consume updates to this component without running the generator again.
Of course there are plenty of more stuff that has been fixed or refactored such as; the build pipeline that has been upgraded to Gulp 4 and Webpack 4 and improved logging in the generated solution using the debug module – and you can read about the other changes in the change log.
It’s exciting times in Microsoft Teams Apps land! We now have a corporate store for Teams Apps, we’ve seen that the SharePoint and Microsoft Teams product groups are having secret meetings to improve the integration between (my favorite) two services. I’m of course looking into this and will share some exciting updates when we close in on more public reveals of features – Microsoft Ignite mayhaps. Oh, if you’re at Microsoft Ignite, try to find me somewhere in a Theater session or lurking in the SharePoint and Microsoft Teams booths if you want to discuss the generator.
In our client-side solutions we can call out to web services and fetch data and present to the user and even allow the end-user to manipulate this data. For a while now we’ve had limited access to Microsoft Graph, where Microsoft has done the auth plumbing for us, and now in the latest version (1.4.1) a whole new set of API’s to both call Microsoft Graph, with our own specified permission scopes, and even custom web services protected by Azure AD. Very convenient and you can build some fantastic (demo) solutions with this to show the power of UX extensibility in SharePoint Online.
However – there are some serious security disadvantages that you probably don’t think or even care of if you’re a small business, a happy hacker or just want to build stuff. For me – designing and building solutions for larger enterprises this scares me and my clients…a lot!
No Script sites and the NoScript flag
Depending on when your tenant was created (before or after the addition of this setting) your default settings may be different. My recommendation is, of course, to Prevent users from running custom scripts, to ensure that you don’t get some rogue scripts in there (see below).
This setting can also be set on individual sites using the following SharePoint Online PowerShell command:
Script Editor Web Part – the wolf in sheep clothes
“Our favorite” SharePoint extensibility mechanism, specifically for the citizen developers (or whatever you prefer calling them), has been the Script Editor Web Part (SEWP). As an editor of a site in SharePoint we can just drag the SEWP onto a page and add arbitrary scripts to get our job done and we’re done.
The aforementioned No Script setting will make the Script Editor Web Part unavailable on these sites.
The Script Editor Web Part does not exist in modern SharePoint. The whole idea with modern SharePoint and SPFx is that we (admins/editors) should have a controlled and managed way to add customizations to a site – and of course SEWP is on a collision course with that. Having that option would violate the whole idea.
SharePoint Framework and Microsoft Graph = power?
How does this relate to SharePoint Framework then? As I said, with SharePoint Framework we now have a very easy way to access the Microsoft Graph (and other Azure AD secured end-points) with pre-consented permission scopes. As a developer when you build a SharePoint Framework solution you can ask to be granted permissions to the Microsoft Graph and other resources. The admin grants these permissions in the new SharePoint Online admin center under API management.
For instance you want to build a Web Part that shows the e-mail or calendar on your portal page, you might want to have access to read and write information to tasks. The possibilities are endless and that is great, or is it?
I think this is a huge area of concern. Imagine these user stories:
“As a user I would like to see my calendar events on my Intranet” – pretty common request I would say. This requires the SPFx Web Part developer to ask for permissions to read the users calendar.
“As a user I would like to see and be able to update my Planner tasks” – another very common request. This requires the SPFx Web Part developer to ask for Read and Write access to all Groups (that’s just how it is…).
Both these scenarios opens up your SharePoint Online solution for malicious attacks in a very severe way. Of course the actual permission has to be approved by an admin – but how many admins do really understand what’s happening when the business cries “we need this feature”.
You still think this is a good idea?
And what about the second user story; where we need full read and write to all the groups, just to be able to manipulate tasks in Planner. It’s not much you can do, if you’re building this web part – you are opening up for so many more possibilities for “working with” groups and its associated features. This is not a SharePoint Framework thing, but a drawback in how Microsoft Graph works with permissions and the lack of contextual or fine-grained scopes in Azure AD. Same goes for reading/writing data from SharePoint sites – Azure AD/Microsoft Graph cannot restrict you to a single site or list – you have access to all of them.
Remember how SharePoint Add-ins have Site Collection or list scoped permissions. I guess you all remember how we complained back then as well. That was some sweet days and we really want those features back. Well, we still have them – SharePoint add-ins are probably the best way to protect the users and your IP still…
As I stated above, of course all SPFx solutions has to be added to the tenant app catalog – but, we also have the option of a site collection scoped catalog. So that’s another vector for insertion of seemingly nice solutions that can take advantage of the permissions you granted on a tenant level.
The grey area between modern and classic sites
Currently most SharePoint Online tenants is in a transition period between classic and modern sites. That is, they have built their SharePoint Online environment based on the “classic way” of building stuff, most often requiring script enabled sites. And now they want to transition to modern sites, without these scripting capabilities. Should they just add the new modern Script Editor Web Part or should they turn of scripting for all sites?
If you turn this off I can almost guarantee that a lot of your sites will be useless. And in many cases your whole Intranet – specifically this happens with many of the “Intranet-in-a-box” vendor solutions. So be careful.
So, what should I do?
If you still think it is very valuable to build solutions with SPFx and Microsoft Graph the first thing you MUST do is to ensure that there is not a single site in your tenant with scripting enabled. You can do a quick check for this with this sample PowerShell command:
I wish we had this kind of notification and warning in the permission grant page in the new SharePoint Admin center. To make it very obvious for admins.
Secondly, be very thoughtful on what solutions you are installing in your app catalog. Do you know the vendor, do you know their code, is their code hosted in a vendor CDN (warning signs – since they can update this without you knowing) etc? Do you have multiple vendors? Who have access to do this?
So, you really need to do a proper due diligence of the code you let into your SharePoint Online tenant.
A note on the CDN issue; when you add a SPFx solution to the app catalog all “registered” external script locations are listed. But this is not a guarantee. It’s only those that are registered in the manifest. As a developer you can request other resources dynamically without having them show up on this screen.
I hope that this gave you the chills, and that you start reflecting on these seemingly harmless weather web parts that you install. You as an admin, developer or purchaser of SharePoint Online customizations MUST think this over.
Do we have a plan to move from script enabled sites to ALL sites with no custom scripts enabled
Do we have the knowledge and skill to understand what our developers and vendors are adding to our SharePoint Online tenant
Do we understand the specific permission requirements needed
I also hope (and know) that the SharePoint Framework product team listens, this is an area which needs to be addressed. We want to build these nicely integrated solutions, but we cannot do it on behalf of security concerns. And it’s NOT about security in SharePoint or SharePoint Framework it is about how web browsers work. What we need is:
Visibility – make it visible to the admins what is really happening in their tenant; script enabled sites, SEWP instances etc.
Isolation – we need to be able to isolate our web parts, so that they and their permissions scopes cannot be intercepted or misused. In the web world I guess that Iframes is the only solution
Granularity - Azure AD permission granularity – it’s not sustainable to give your applications these broad permissions (Group Write All). I want to give my app access to write in one Planner plan only and not in all groups.
Thanks for reaching the end! I oversimplified some parts, but if you have any concerns, questions or issues with my thinking – don’t hesitate to debate, confront, question or agree with this post.