Microsoft 365 Community Graph, 5 Feb 2021

Previous Meeting Next Meeting

⏯

youtube image

►

From YouTube: Microsoft Graph community call-February 2021

Description

This month's Microsoft Graph call featured Microsoft Graph Cares Team to talk about Microsoft Q&A, Search API General Availability and SharePoint Site Collection Level Permissions demo. The host of this call was Sebastien Levert.

Speakers: Kendall Burns, Nicolas Moreau, Tong Zheng, Jeremy Kelley.

Resources:
•See the full blog post for this at https://aka.ms/M365DevBlog
•Microsoft Q & A – Graph - https://aka.ms/askgraph/
•Endpoints in MS Graph
- https://graph.microsoft.com/beta/search/query
- https://graph.microsoft.com/v1.0/search/query
•Microsoft 365 developer community calls – https://aka.ms/M365DevCalls

Next Call:
• March 2 at 08:00am PST https://aka.ms/microsoftgraphcall

Follow us on Twitter https://twitter.com/microsoft365dev

A

Thanks everybody for joining this monthly microsoft craft community call. We are february 2nd 2021. Our second call of the year, where we're gonna have three really really cool topics. Today, where we're going to discuss something new that we're uh kind of announcing today, regarding microsoft, q, a we're going to talk about the search, api, ga and we will be discussing about the sharepoint site, collection level, permissions for microsoft graph, so quite excited about all these topics today. So a lot of people will be joining the call today.

A

So that's great, so we're going to have to do a little bit of a speaker, a dance to go over everybody. I'm super excited to have all of you today.

A

If you are interested into presenting a community led presentation in this call, we'd love to get your session in so reach out to us, either to brian jeremy or myself.

A

Please include in there the solution and the topic that you want to cover uh the different graph api that you want to talk about, and also what are different platforms and maybe services that you are using in that presentation. Then we're going to be able to give you one of the spot in the future uh sessions of the graph community call. So without further ado, let me go on and give the floor to kendall from the microsoft graph cares. Team.

B

Thank you so much um hi everyone good morning, good afternoon, I'm here today to talk about a microsoft q, a so um microsoft q a has been around now for about um a little. Over a year we launched it in october 2019 with the nine services, and today we have over 200 so, and that includes microsoft graph now, so I wanted to talk a little bit about that um for those that are wondering. Where do I go? We made a short link.

B

You can go to aka dot, ms ask graph, and that will take you to the page where you can find the graph, microsoft graph tags, and you can ask a question about um any of the graph topics that you're wondering about so a little bit about the process. So we actually turned on the microsoft graph tags in october and um we have a dedicated team that that we have had here of experts who have been answering the microsoft graph tags on stack overflow, and we will continue doing that.

B

But we have now grown the team and we were are now answering questions on microsoft, q, a as well so we'd like to encourage you to try out microsoft, q. A next time. You have a question for microsoft, graph. Also with our team. We launched the azure active directory tags a little over a year ago, and we now have more questions per day on microsoft, q, a than on stack overflow. So we feel really good about the experience that our customers are having and yeah.

B

We're really excited to have you so one of the reasons why we are promoting microsoft. Q, a is because microsoft owns the platform and we've been able to integrate really well with our learning materials and our support as well as future integrations with our support. Tooling and insights like we have in the azure portal today, we can also do private chat.

B

So if you've been asking a question- and we have some questions for you that are more specific or maybe a little private to not share in public, we have a private chat that the microsoft support person and the original poster only they can see. And then we post the answer publicly, um removing all pii from the from the question um and there's there's more features that are coming all the time. So one thing I wanted to point out is the instant answers.

B

So if you're wondering what are all my questions that I asked on uh msdn and technet forums, those have all been moved over as well. So if you start typing your question, you'll be able to see uh previous questions that you had asked in those forums as well, so um yeah. So that's that's what we have and can't wait to have you over there and we'd love to hear feedback from you as you start using it, and let us know how we can improve the experience for you.

A

Excellent, thank you kendall. So everybody go right now. Aka ms slash ask graf and I think that's going to be a really really cool place where you can engage with the rest of the microsoft graph community. Thanks for your time, kendall, I appreciate it. Thank you now. Let's move on to our second topic today um regarding our search uh api that went uh in general availability a couple of uh weeks ago, so nicholas and tong. If you want to take over the screen floor, is yours.

C

Yes, thank you. Let me show you my screen.

A

C

Hello: everyone, my name, is tong jung. I am a developer in graph search api team. Today I will talk about the graph search api with nicholas first, let me give you an overview of graph search api.

C

Then I will walk through current supporting api features. Finally, nicholas will.

B

Introduce future supporting.

C

Features in the next six months. First, let me give you an overview of graph search api. What is graph search api? It is a search api based on microsoft graph and we can use e2 related, all microsoft, 365 workloads, and we can also expose microsoft search intelligence to both first party and third party developers, and we also have multiple data sources such as exchange resources, odsp resources and connectors.

C

Here are some examples of different data sources for search api.

C

Next, let me show you api capabilities and type of search. Api search. Api has been on body to better and v1.0 endpoints in microsoft. Graph and all the queries from the search api are scoped by entity.

C

Multi different entity types can have different workloads. For example, we can search message, entities in mail and event, entity in calendar and external data in connectors and multiple entity can also share the same workloads.

C

For example, list item list, site and drive and drive item share, the send workload odsp and all the results from search api are graph entities. Next, I will talk about the current supporting features.

C

They are select properties, source feature and refi refiner feature and connectors feature.

C

The first feature I want to talk about is called selective properties. This feature enables users to trim down the response, properties and access more managed properties from the search index by selecting the properties in the request.

C

Let's take a look at the select properties feature demo in the graph explorer, for example, if we only want the last modified datum and subject property to be written in the response, we need to specify them in the first part of the request, and we run the query in the response: we can get the chain down properties by the property we select in the request.

C

Next, I want to talk about the soft feature in this feature. We can sort search results on sortable properties for sharepoint and onedrive. Let's take a look at the sort feature demo in graph explorer.

C

To enable sort properties, we need to specify the sortable property in the sort properties part of the request. We can run the query and then we can get the search result sorted by last modified datum property in descending order.

C

Let's move that to the slide.

C

And now, let's take a look at the refiner feature. The refiner feature can help aggregate the searching result based on different specified fields and we can support numeric, refiner and string refiner.

C

Let's take a look at the numeric refiner. First numeric refiner aggregate search results based on numeric field. Let's take a look at the numerical refiner demo in the graph explorer.

C

Here we can see in the request in the aggregation path, the numeric field is size and the corresponding definition is specified here.

C

The value of the value ranges of the size field are defined to less than 100, and between 100 and 1000 and more than 1000, we run the query.

B

C

Get the aggregation response in the aggregation part of the response we can see. The numeric field is size and all the search results are aggregated into several packets and this uh corresponding to the packet definition. We define in the request any question here.

A

There are no no questions so far in the chat feel for everybody. If there is a question, feel free to add it to the chat, and I will be able to ask you to tongue.

C

If we don't have questions, let's go back to the slide.

C

The next I want to talk about is the string refiner string, refiner aggregates search results based on string field.

C

Let's take a look at the string, refiner demo in the graph explorer.

C

In the aggregation path of the request we can see the stream field is file type and we run the query.

C

We can get the aggregation path aggregated by file type in the aggregation path of the response we can see, the string field is file type and all the search results are aggregated into several buckets and each package defines a value of the file type and the number of this file type and and the unique token based on this file type and can be used in the aggregation filters.

C

Any questions here.

A

There is no filter related question. We have three questions you might. I might want to park them by for the end of this specific section, so I would say tong we can continue and when you're going to be done, I think we're going to be able to ask some of these questions as they're more general to search.

C

Okay, okay, got it thanks, so let's move back to the slide.

C

The next feature I want to talk about is the connectors features. This feature enables users to get the third party data through connectors. Let me share connector's features in demo in graph explorer.

C

We can see in the request the entity type of connected search, is external item and the connector as specified in the content sources.

C

We can run the query and in the response we can get the data from the connection with we specify in the condensers of the request.

C

So let's move back to the slide and now, let's welcome nicholas, to introduce capabilities that we are going to support in the future.

D

Okay, hi everyone. Sorry I'm in the dark, not because I like being in the dark, because I have some partial power outage in my house, so yeah I was able to get power to get here. uh Okay, so first thing that we're doing so as we are now in 1.0, we are officially in um released. We are doing just as a heads-up. We are doing some work on availability perform improvements. uh We are allocating cycles to be there once we get questions when we get potential breaking things we we need now that we want 1.0.

D

We are making significant investments on making sure that the api is really rock solid. We've been doing that, but I just want to call it out here from a feature capability in terms of feature. What are we adding? So in the current search api?

D

We are adding spanning correction, so this is the box in the top right, so typically to power when you mistype something: oh did you mean that so we are gonna, add this capability uh most likely in the in the wave of probably a little bit before build uh in sometime in uh april or march. That's something we are planning to edit. We why we are adding. This is because this is a basic capability that any search platform should provide the ability to do some spell correction.

D

The second thing we are adding for those of you who are familiar with connectors connectors for connectors. You define the schema for each connector. The problem is, if you have a connector, which is a servicenow ticket and another connector, which is a sql database. That index, I don't know products you need. There is no way to previously the you need you needed to specify the property of the first key mind of the second schema the connector schema has introduced.

D

The concept of semantic label is even though different data source, so tickets, for example, and products have different schema, there's a way to tag and to say actually, this property is the title of the of the element of the item. This uh this property is the url of the element.

D

This property is the description of the element, so once this is done on the connector stand when the connectors are configured this way, the thing that we're enabling with the search api is that you have the ability to query the item and you request the property, as tong has been showing that we call select property and instead of passing the actual name of the field in the ticket schema or the field in the product schema.

D

You can provide the label and say, oh, give me title, give me description, look the light is back description and then, and then url. So that's the good way to if you are acquiring across multiple connectors, you have the ability to um literally have a um a kind of a common schema for the connectors.

D

uh The third thing we are planning on adding is supporting adaptive card in the response for connectors, because in connectors you in the admin ux, you can configure an adaptive card that we call these modern, modern result. Type modern display template templates. So we think in the in the search api. It would be good if we given, we have a an element of ux to help render. uh We are planning on giving that, because today we just returned the raw data, we don't return anything to display.

D

So these are the three I would say, features on on query that we want to add from uh from the type perspective, we are planning to surface people in slash query today they are not showing up, so we are planning on adding that and the second thing is adding editorial bookmark q and a acronyms. These are things that tenant admins enter in the search admin ux. So this is bookmark as the replacement of person of favorite or best bets in sharepoint.

D

That's kind of the modern way to do that. uh Q. A is a little bit the same like uh what? What are my benefits? You? Can you can kind of hard code, some specific search, query with some um with some url, so we want to make this data accessible via query, because we think I mean that's, that's just data and we want to surface it, and this is something. That is uh why we want to surface.

D

It is because customers have spent time entering this content in that mean ux, so this is kind of high value content for the customers.

D

Third thing: we are planning to add a new endpoint, so today we have slash query which gives you the full recall. Literally, you can paint a search result. We are planning to add suggest, so this is the second diagram on the right. So typically this type as you, the one, the one in the down there, you type microsoft, search- and it is suggesting you here- are some files here- are some sites, your potential text, to help you to formulate your query.

D

So this is something that we are planning to add in the build-ish time frame, and then the last thing we are spending time on is building a search sample. uh We want to have a search sample that can showcase what the capabilities are. We want also these samples to help get kind of more business discussions with these customers to see how this is the type of things you could do with search to give customers ideas on how they can leverage search uh for their own business.

D

For some for some of the business center, so we're just starting something something here. I know there's plenty of the other search sample and I'm thinking also on the patterns and practice side. There's the universal search, there's a lot of things, but we want to do something very targeted for for the for this api.

D

So this is what we have here. There were a bunch of questions. Maybe can.

A

D

A

Absolutely absolutely absolutely I'm gonna go through uh some of the questions that were not answered. Some of them were answered in the chat, uh but here one of them is regarding q. A um is that just setting the q a but also will be able to consume the q, a yep yeah. So.

D

There's both yeah there's, both so editor, bookmark q, a acronyms I think, there's another one. So there's we want to make search manageable via api, so you would be able to build an app typically where you can enter a retrieved qna instead of going through the search admin. So that's one thing management and second retrieval via slash query: that's really cool! That's.

A

Very good thanks for that. The other question is: do from a sharepoint site perspective, as this is one of the entity that can be retrieved. Do you get the metadata regarding these sites uh attachment of data? I think it was something that might not be there in beta back then, but do we have all of that available as us today, so.

D

That's the problem: research in search. We have some metadata but search the search index doesn't get the full data that, for example, a file has we have some. We have some information in uh in the search index, but not all of it, so uh the guidance is. If so, we are not doing a great job documenting what are the properties available? So I'm thinking in the context of sharepoint literally, we are leveraging the managed metadata concept in sharepoint, so you have to know the name of the management editor.

D

That's one thing: I want to push the team overall, even with sharepoint, um to be to do a better job documenting the at least the out-of-the-box schema. And if the metadata is not there, then you need to do an additional call, a get call to actually get the metadata which you didn't find.

A

Excellent, I don't see any search related questions. I see a couple of questions that are not search related, we're going to keep them for a q a at the end if time permits- and I think all the other questions were answered, especially regarding- what's the technical way of filtering on aggregation filtering all these kind of things, so I think that we covered pretty much all the q a thank you very much nicholas and tong that stayed super late for us today.

A

We really appreciate we're really excited about the search api, so thanks for jumping on the call today, I really appreciate it now. Let's move on to our next topic, which is, I think, another very popular discussion that we've been having in the last couple of weeks. Here is around sharepoint site collection level. Permissions jeremy floor is yours,.

E

All right: well, let's go through the slides quickly and then we'll get to demos. So a brief history of sharepoint app permissions. Anyone who's, you know worked in building apps for sharepoint. Probably already know knows this stuff, but sharepoint add-ins classically could be installed per site collection.

E

So when you installed into the site collection, we wrote some data into a table. That said, this, add-in gets to talk to this particular set of data and all was well.

E

It could even be restricted to specific lists, which is great, but when we moved on to building apps that talk through microsoft graph, we only introduced permission scopes that allowed for all or nothing so you're, building an app and either you get access to the entire tenant or you get access to none of the tenant and that's not awesome like we can clearly do better than that, and so we've certainly been hearing the feedback frequently that this was not going to be acceptable really for just about anyone anymore, um especially in light of kind of the increased focus on app security.

E

So we finally decided to do something about it. We've been working on this for a while, and we think we have the start of a solution. Some things to set in context for what we're doing the stuff we're going to talk about today are just a step on a much larger path.

E

We believe that, ultimately, there needs to be a unified and consistent solution that works across all of the workloads in graph, and so I've been working with philippe on the aad team to really make sure that if we took this first step, were we making sure that it was along the direction we wanted to go long term so that we can get all the things that we want and we think this does. We think this is a necessary first step.

E

It's not perfect, it doesn't solve all the scenarios, but it gets us moving and will certainly enable a bunch of scenarios that are going to be really important for people to start working with so we're targeting application. Only to start we talked about delegated, we will eventually get to delegated, but for the particular things we had in mind that we wanted to get working first, we felt that targeting app only was going to be the right first first piece and in this first I'm calling it phase one for lack of a better term.

E

The solution kind of requires engagement, both from client app developers and the iet department. It's going to require a fairly sophisticated level of engagement with it and you'll see why, as we get to the the demo, primarily we didn't build any ux around this feature, so it requires actually using a new graph api to interact.

E

We're calling kind of this is kind of sharepoint flavor of rsc.

E

I don't like the resource, specific consent term for this, because really you're granting a consent to the app um you're, not granting a consent to the resource, in the same way that I think that term means to a lot of people and it's a confusing enough area that this is giving people the ability to set permissions, not so much setting consent.

E

So this will allow admins to control access per site collection, as I mentioned earlier, sharepoint add-ins could go to the list level. We didn't expose that yet um it's kind of in our back pocket for when we think there's a real need for it. When we start to hear feedback, it will be something that we could open up. We haven't yet um right now we're going at the site, collection and there's two components.

E

uh One is new api endpoints in graph that require sites.fullcontrol.all still so you can imagine you need an application that manages permissions likely held by the iet department.

E

In order to say you have the authorization to set the permissions, you need a fairly broad scope, so we imagine there's component a an app managed by it that calls this new permissions api on the site object.

E

The second component, then, is your client app in this case, whatever it may be, whatever it needs to do. Can now request the sites.selected permission, scope, which some of you may have already seen in the ux in the aad portal, and so that we it's interesting trying to sim ship features with other workloads.

E

So we got the permission, scope launched uh that took a while to get everyone on board and shipped, um and it ended up shipping before we got the rest of the api so that permission scope is available in the the portal today and uh hopefully in this week's deployment of the graph schema you'll actually get the other part. You need to work with this, which is the new permissions api and the sharepoint section.

E

The new endpoints we are adding, as I said, require sites.fullcontrol.all requires app only for now. We've had discussion about whether we open this up specifically for a tenant admin delegated permission as well. We can add that check if we need to the initial implementation requires app only and, as I said, you basically have two apps or n apps in this scenario.

E

App one is the thing that it will own, which is the thing that sets the permissions and app 2 through n are the the apps that need the permissions set and request sites dot selected.

E

The way that we've made this work is we've added. The permissions object to the site object in the graph, so this is very similar to the permissions object that already exists on files similar structure.

E

So if you want to get the list of app permissions, you do a get on the permissions endpoint, adding a new permission as a post, and then you can get patch and delete the individual permissions by id, which will come back in the overall permission. Get the demo I'm going to show today uses actually an earlier implementation, where we were reusing the invite endpoint.

E

If anyone was on the tap call a while back. Where I presented this, there was some feedback there that that wasn't great. We got the same feedback when we went to to our graph review, so we decided to go with the permissions object instead, but the demo that I have set up is still using the old, the old method, so same concept, different endpoint.

E

I didn't call out the the data structure here, but the docs for this uh should also ship either this week or next week. That'll give you all the details.

A

We have a couple of questions that might be of interest before we move on to the demo, so the first one from paul is do right now. Does implementers of that will need to build the ui, the the functionality to add the permissions, but will that end up in the product from a ui standpoint.

E

So that was kind of our in the future. Yes, we believe that, in order for this to serve all the necessary audiences, there needs to be a ux to manage this. For this first release, there is no ux. It requires you to build kind of an app management. That's why we think this isn't necessarily going to work for large isb scenarios, necessarily where you're trying to sell a boxed product going to your customer and saying hey.

E

I've got this thing that you can buy, but you need to do a whole bunch of work to build your own app, not great. The scenarios we specifically had in mind were kind of enterprise dev scenarios where you have an iet department and an in-house dev department working together for building line of business apps. um I don't want to call out partners by name, but we had some canonical examples of this where you could imagine.

E

You are working both with your business's customer data and you want to build an app that only works on your customer data, but doesn't have access to your hr data. Your finance data right, you have kind of more siloed within your enterprise scenarios.

E

In those cases we imagine you will have a better understanding of specifically which site collections an app needs to have access to. They should map into a fairly small set that building a management app for those permissions isn't too terrible. Hopefully we will also be able to ship some sample code. That gives you a starting point that you can just customize to your needs so that everyone doesn't necessarily have to write it over and over again, I don't have a committed timeline on getting a sample app out there, but it's fairly easy to work with.

E

So that's the long way to say ui in the future. Today, it's app only- and I think there was another question about- can you use the powershell sdk? That is certainly my intent that we expect that you know we're. We didn't end up putting this on the legacy sharepoint apis, specifically, because we thought we would get a lot of benefit from graph having the powershell sdk already. Not us not having to go. Do a bunch of other work to to get those benefits, so that should be totally viable makes.

A

Sense one question that was from paul: the other paul uh was: um is there the opposite, basically treated as a uh instead of just saying which sites you want to get grant access? Do the opposite like deny access on a specific list of sites, yeah.

E

My original spec for the feature specified both we for, like. I said we wanted to get this first bit out first, so we had to keep the scope fairly narrow in the fullness of time. We expect that the means to craft the policies by which your your app access is shaped um become a lot more advanced and we're working with the aad team to figure out which feature set. Does this go with? How do we express this? You know.

E

Ultimately, you want to be able to say you know I want all of the onedrive for business accounts, but not all of the sharepoint sites, and you know stuff like that, or I want only users who are in this particular security group or who only site collections that are tagged with this particular label. All that stuff is as asks we've heard, but in the interest of getting a thing out first, we didn't want to hold up for the all-singing, all-dancing version.

E

Yet so, yes, that is our vision. I don't have any more, you know. What's the next click stop and timeline, I'm still working on that. That's.

A

Great and maybe one question before we can go to your demos, because we have a question around availability. I think we're going to cover that at the end, but as as an application developer, your app might have access to multiple sites. Do you have a way to actually get the sites that you have permissions to? So you can kind of iterate through x number of sites.

E

We don't today, I think, that's something that we will have to solve in that next iteration.

E

The way that the permissions are stored doesn't lend itself to an efficient way for us to tell you all the sites kind of gory sharepoint implementation, details that interesting to like two people that prevent us from really easily giving you the full set, but I think we will need to figure that out. Ultimately, it's certainly in the back of our head that that's a thing, that's missing right now, right now, it's kind of like I said it's designed for a scenario where you know up front hey. I need to work on these five sites.

E

They're configured and both it knows it and the app developer knows it, and so you can manage a static list somewhere outside of sharepoint. That is not a perfect solution. It's not a great scalable solution, but it is you know it's the starting point and we think there's enough, we think there's enough value in what we do have to help people get unblocked. While we work on the next set of set of things here, I will share my screen.

E

All right, so we've got a couple components as I we have our client app and we have our permission. Grantor app, you can imagine if you haven't seen it already. This is the azure portal with the graph api permissions, so under application permissions. Now, if you come down to sites you'll see sites.selected, um that's really the only thing that your client app typically will need for this scenario.

E

If you granted a broader scope access, it will get the broader scope access. So keep that in mind. Generally, you don't want to request both a broad and the selected scope. That's not great! If we look at the code, though, for kind of that the client app there's nothing special in here, all I'm doing is executing some basic graph calls. This app in particular, has kind of come up as I've been transitioning to the latest and greatest versions of microsoft microsoft.identity.web.

E

So this code works, but I don't know if it's the perfect way to do what I'm doing. I haven't gotten a chance to fully update. Yet this is kind of making manual request manual requests, as opposed to using the the graph library which I prefer to do, and once everything, ships and a new version of the client libraries are out, I will update.

E

Basically, I have a url here which is just saying: hey: go x, go get the metadata for this particular site and I have two sites configured in my demo tenant, one that we're going to say we do want, expect to have access to and one that we shouldn't, because we've got sites.selected coming back. So the first one, I think, is the correct site. It's called company coms and the second one here we expect to fail and it's called above top secret, so we're gonna come over.

E

Let's take a look at that uh in the browser we want this one, so I already loaded the page, but you can see the entire purpose of that that web app is just print out hey.

E

We didn't get access to the thing that we wanted to, but we did correctly not get access to the thing we didn't we shouldn't have access to. So that means that, right now we have sites.selected, but we don't have application permissions set on the objects that we need to go get like those sites have not had our application added to the list. So if we look at our other app, so we've got kind of our now. We've got our it management app. It's gonna do a couple things.

E

It's gonna this app that I've written is basically just a test app. It lets me enumerate all the permissions and it's gonna. Let me add a permission.

E

So in this case I'm just doing a get on the permissions endpoint to do the enumeration, and then I actually look at the individual permissions that come back and query each one to find out what roles are associated, so this will have.

E

I can either grant read or write or the combination of the two read and write, and so I need to actually ask the individual permission here for its details in order to find out what roles it has associated with it, and then the other method we need to do here is add the app permission.

E

As I said, this particular app is using an older implementation, so it's calling the invite api imagine this is calling a post on the permissions endpoint instead with slightly modified input and it would work but based on my ux, I'm either adding read, write or both sending the request off and if it says it gave it to us, then we print out granted and if not, then we print out our error details and I'm really hoping we don't actually see that as we go over to the app.

E

So let's take a look at how that works, so we're going to switch over here. I've got this nifty test app we're going to enumerate all the sites in sharepoint. If you haven't played with our new sites enumeration endpoint, this is going to use that endpoint to list out all the site collections and my access token expired. We're gonna sign back in.

E

You can tell it's a test app because I didn't do a whole lot of error. Checking.

C

E

All right here we go site enumeration, get all the sites fingers crossed all right. So here's all the site collections in our demo tenant we can see here are those two sites that we were. We were looking at uh the above top secret, which we don't want access to, and company comms, which we do so we're gonna click into the details on company comms. This is absolutely pm driven web ux, there's a whole lot of nested tables. Here, don't be offended.

E

If we go to permissions, I can list out and we can see at the top here. We've got an empty table, no permissions. So what we need is the app id of the app we want we're going to give it a name and then just which permission we want. So I'm going to jump over real, quick grab. My app id come back.

E

Call this limited app. Let's grant it read, I hit submit permission granted. It says. If we go back, we can now see at the top that table is filled in so there's an id associated. With the permission we just added.

E

We know that it has read access and it was granted to this app id that we gave this title. The title is really just free form text, it's much easier. If you make it the actual name of the app, we aren't doing a lookup on it. The thing that really matters is the app id from the client id from the azure portal, and if I wanted to delete this permission again, I could push that, but we haven't actually seen this working. So I'm not going to do that.

E

Yet we're going to go to our limited app, I'm using the same tenant credentials. So it should just sign right in wait for the redirect and we saw before it said we didn't have access now. It says we correctly got access to the site. We should and we failed to get the site we shouldn't, and we can do this just to show that it's live. I can go over here and delete the permission.

E

Come back refresh this page and now it fails to get the site so real easy. I call the permissions endpoint to add an object, add the permission and I get access. I remove it. It goes away instantly. So we think this is a big first step, um certainly better than granting sites.fullcontrol.all to every app that comes along. I can share that.

E

You know our own I.t department has been not granting a whole bunch of apps, because people want to talk to sharepoint, but they don't have a way to to do this, so we are certainly working with them so that we can adopt it internally for some scenarios, and I hope that this is useful to you in terms of timelines. As I said, this should be going out in this week's deployment of the graph schema so anytime this week early next week, you should see the permissions endpoint on sites light up. The permission.

E

Scope is already in the the aad portal and the docs will ship also soon I was reviewing them last night and something wasn't quite working, so we have one bug in the docks to fix, and then we should get those out also and we'll do a blog post on other announcements.

E

So you should see that, but super excited to have this shipped. This has been a lot longer project than we thought when we first started it, but we're glad that uh it's becoming available and people are going to be able to play with it.

A

This is amazing thanks thanks jeremy. I think you answered quite a lot of the questions by this last segment around date, so everybody try graphics, floor, you're, going to see that coming actually not even graphics store because that's delegated, so it's going to have to be app only for that, um but I think we're gonna uh have this. There was one question, maybe for you, jeremy, and maybe you can elaborate just a little bit.

A

You showed the example of a site enumeration from a nap only standpoint where so I know it's it's available as part of beta right.

E

So site enumeration is actually available in 1.0, okay, we haven't made as much noise about it because we're trying to get delta to work and really for that scenario to light up, you need delta.

E

So we haven't made the the big announcements until we get delta working where we're kind of hoping it would happen at the same time as the app permissions, I may put them in the same blog post anyway, even though it's not quite there, but if you just do a get on slash sites with app only permissions, you will get the list of all site collections today that includes sharepoint team sites, com sites and onedrive for business user sites.

E

It will, in the future, include teams sites. Today, teams are not included back when we started the feature we were making a decision. That teams stuff would be managed through teams. Sharepoint stuff would be managed through sharepoint we've flipped that decision and said no. We actually want team sites to be included in site enumeration, so that will be coming shortly.

E

I will follow up on why the docs aren't under the 1.0 endpoint. It should be there. They might be there, it might be.

A

Just not in the table of contents.

E

A

E

It could also be we messed up somewhere that that's possible. There's.

A

A lot of steps.

E

In publishing to graph- and we try to get them all right.

A

Yes, definitely uh one question we have is: where can we find documentation around all of that site, collection, level, permissions.

E

The permissions object, I believe, will be linked off of the site object because I don't remember if it's a relationship or a property, but it should just be in line in there, so we have for those that are familiar. We have something we call our scan guidance which is really about how to do large scale, processing of files in sharepoint onedrive, because this isn't really ready for isvs and kind of building those large scale apps, I'm not sure if we're going to. If I'm going to include it there.

E

I haven't quite decided it's a relevant topic, but I don't know that it's usable in that scenario. Yet so, at the very least, the permission, the site permission, object, should get linked in the site stocks. uh When that, when that ships, I think that's what the toc is updated. So.

A

It's going to be synced with the the shipment. Basically, once everything rolls out, documentation will be published and then it's going to be available, cool well um yeah! Thank you, so much jeremy. I think this is one of the big moment for for uh sharepoint and graph. It's something that has been asked so much in the past, and I think, as I see in the chat, people are quite excited about it. So I wanted to give you a big thumbs up on that.

A

I think people will be uh really really happy to start leveraging it and and something even though it's a pm pm-based app that you're showing right now. I think a lot of people will would love to get that to start playing around so just as a fyi. If you want to publish something there, community.

E

Work, I know I keep wanting to. I have to do some some redaction to make sure my app ids and other secrets don't leak. But, yes, there's nothing super confidential about what this app does. This is basically just we built it to test site enumeration and I just kept going from there as we built more and more features. So there's a whole lot of code here and I want it to be up to standard before we release it as a sample. That's perfect that.

B

E

Getting the off stuff to work consistently and all that other stuff.

A

That's right: let's, let's sing together, maybe I can help you on that one one question before we: uh we end up this segment any plans on on gcc. For for this, will this be rolled out at the same time or it's going to be in phases.

E

Gcc is a good question: there's a bunch of gaps right now with sharepoint. We are sorting out some publishing issues once we do. I don't expect this to be blocked from there. I don't know if the I I will have to do a little more research to know if the permission scope needs to go somewhere special for gcc.

E

I think it's just the graph schema. We have to publish into the gcc environments. There's.

B

E

No intent to hold it back, it's just a matter of us getting our publishing process cleared up.

A

Perfect accent here I see it's gcc, but not just gc, but gcc, high, so cool, so we'll be able to uh to uh follow up on that. It is now uh three before the end of the the hours I wanted to kind of invite you all to join our tap program. You can see the url here where we go in workload. More deep, dives lots of notifications around the upcoming features, a little bit of case studies and also sharing your feedback and future requests around graphs over here.

A

If you want to join, feel free to use that link, we're looking for more partners and customers to join so feel free to use that link to join us. We also have a list of other microsoft. 365 developer community calls so please go to the akms m365 dev calls where you will be able to see.

A

All of these calls and kind of uh cherry pick, the ones that you uh want to join, based on your interests and the technologies that you're using so please feel free to jump in there's a like an amazing list of content that actually happens throughout the m365 dev community. So please feel free to do so.

A

Also, our two favorites of uh the community calls jeremy and paul jeremy taken fly that are hosting the m365dev podcast, which is absolutely amazing, and we have had a great topic in the in the in the past, so please feel free and subscribe to this top podcast. I think that's my way of learning about what's coming up in the m265 dev space, so really really big thumbs.

A

Ups on that last one, we have launched a new blog series, which is called the microsoft graph mailbag, where we uh as part of the graph team, but also a broader team. We share insights and different lessons learned around microsoft graphs, so we're publishing twice a month on the second and the fourth tuesday of every month.

A

You can get access to the mailbag to the kind of the wrap up of the mailbag or the the list of all the blog posts on the mailbag on akms, ms graf mailbag there's huge contributions happening there, there's a lot of them actually happening and if I'm not mistaken, we're going to have one next week. So that's going to be an interesting one by one of our colleagues, fabian williams, so everybody thank you so much for joining us today. The recording will be available soon on our m365 dev youtube channel.

A

Please follow us on twitter and the next call is on march 2nd at 8 a.m. Pacific time feel free to join in thanks everybody, and I will wish you all a great day cheers guys.