How to exclude deleted users/groups from Azure DevOps API Response - azure-devops

Referring to https://learn.microsoft.com/en-us/rest/api/azure/devops/graph/groups/get?view=azure-devops-rest-6.0 that tells that 'The group will be returned even if it has been deleted from the account or has had all its memberships deleted.' - it is interesting how can I exclude deleted users/groups and get only 'clean' and actual response from Azure DevOps REST API, without deleted objects?
It looks that documentation above does not include filters to do that. At the same time, data that is returned (sample is given in documentation) does not contain any flags that would allow to do any filtering on client side.
Trying to search the internet did not bring any success so far.
Is it possible somehow to exclude deleted objects from Azure DevOps REST API response?
Thanks in advance.

The API you referred is getting a group by its descriptor. The descriptor is the primary way to reference the graph subject while the system is running. This field will uniquely identify the same graph subject across both Accounts and Organizations.
If the group is deleted, you'll see "isDeleted" argument is set to Ture. Check the screenshot below:
If you want to list all groups, you could use Groups - List api, this api won't return the deleted group.

#Cence Dong shed the light in his answer, but since I cannot attach images to comments - I post answer here.
isDeleted - property appears dynamically in each response in case the object was deleted.
Cance Dong showed example for getting group request using descriptor and mentioned that it won't happen if you get Groups List. However, my observation is (screenshot attached) that the same happens for List as well.
Conclusion - isDeleted property appears in all type of group requests if object was deleted.

Related

View user group limitation

We have a number of groups that come from Azure Active Directory.
Some groups contain more than 200 Users but the total is limited to 200.
Where can I set that all users are visible in the group so more than 200
This is by design a currently only a design limitation.
Azure DevOps UI will only list the first 200 members of an AAD group.
The limitation is only in what members we display, it does not impact the actual permission assignment. If you need to find the related user, you should search on the specific user directly.
I can fully understand your requirement, I suggest that you can create a suggestion ticket in the Developer Community.

Mapping user email to ADO user/descriptor

With a git commit, I have access to the author and committer's email and I wish to map that to a user in Azure DevOps. I've done some due diligence in searching this up but I cannot find anything concrete. I've basically reached the same state as the following post: Getting user/users details based on user name/alias as parameter in azure devops
I can see on the Graph API page (https://learn.microsoft.com/en-au/rest/api/azure/devops/graph/?view=azure-devops-rest-5.1) that this is not yet officially supported. The problem is as follows: is there a way to get back a user descriptor from simply an email?
Searching by UPN or Display Name
COMING SOON!
Often, identities are represented simply as display names such as
Jamal Hartnett or UPNs such as jamal#contoso.com. These are not
unique at any scope. Search is an resource that will take a text
string and run a search across an account or project to find all
potential matches. The more distinct the input, the better chance the
resource will return a single result. The search resource will accept
display names, aliases, UPNs, and email style strings such as Jamal
Hartnett jamal#contoso.com.
If the commit author email matches the pushed by email, I can use the IdentityRef object from that. But for other cases where this does not apply, I'm at a loss on how to map to a descriptor.
The problem is as follows: is there a way to get back a user descriptor from simply an email?
As far as I know, the official Rest API doesn't support obtaining descriptors by email.
But based on my test, it seems that this requirement is available.
You could get this Rest API in Browser Console tab when you filter the user in Organization Settings -> Users.
Rest API sample:
https://vsaex.dev.azure.com/Organization name/_apis/UserEntitlements?%24filter=name%20eq%20%27user#domain.com%27&%24&api-version=5.1-preview.3
Then you could get the user descriptor in the API result.
In addition , the official Rest API supports to list all user Graph. You could get the user descriptor in the result too.
Hope this helps.

Azure DevOps and Teams - one Group group to control membership to both

I have been trawling the internet and clicking myself blue in the face! Hopefully someone has a definitive answer.
I want to have one Group (in either of Azure AD, Microsoft Teams or Azure DevOps). This group must have access to a DevOps project and a Team site. When I change the membership of the group, the membership must change for both the Team and the DevOps project. I want to avoid the overhead of managing the groups for both separately.
Is this at all possible? Thanks.
This is a really good question, and the answer is not obvious at all. Ironically we had the same exact problem in Microsoft Teams - when a user was added or deleted from the underlying Office 365 Group (which is mastered in Azure AD), it would take up to an hour, sometimes more, to be reflected in Teams, which has its own copy of the member list.
There is a way to do it, and it's how Teams does it: it relies on a relatively new feature in Microsoft Graph called subscriptions. You can find the documentation for it here: https://learn.microsoft.com/en-us/graph/api/resources/subscription?view=graph-rest-1.0.
Essentially what you want to do is create a subscription to the group: POST https://graph.microsoft.com/v1.0/subscriptions with the right message body and your endpoint will be called whenever there's a membership change in the group. Your endpoint won't know what changed, just the event and some IDs - you will likely have to make a separate call to retrieve the actual data (unless the IDs alone are sufficient).
There's a sample on GitHub that illustrates how to use Microsoft Graph subscriptions including more details on how to subscribe to group notifications specifically.
One thing to be aware of is that to use these APIs, your application will require fairly elevated permissions: Group.Read.All which means it has the ability to read not only the team/group members, but all of its messages too (among other things), for every group in your Office 365 tenant. We are working with the MS Graph team to support a less-privileged, per-group permission approach, but even after that's released for Teams Graph APIs, support for that will have to be added to the subscriptions APIs I just mentioned and that may not happen for a while.

AD Azure Graph API does not return directorylinkchanges

I am using differential query feature provided by AD Azure graph apis as described here
Things are working fine except for one issue. The sample responses in the link show that membership changes are sent across as directorylinkchange objects but I do not receive any such objects with similar queries on making membership changes from the portal.
I am doing a GET to
https://graph.windows.net/<domain-name>/directoryObjects?api-version=2013-04-05&$filter=isof('Microsoft.WindowsAzure.ActiveDirectory.Group')%20or%20isof('Microsoft.WindowsAzure.ActiveDirectory.User')&deltaLink=cLbsN4TzLm92uH26XEe7Ph6HfE10VkRsxjmz8 ..[truncated]
I am not sure if I am missing something here as I am able to fetch other User and Group changes. So could anyone working on azure be able help me out on this one. Thanks !!
Ok. answer to my own question is , that the URL filter must contain all three object classes User, Group and Contact just like it is in the microsoft sample.
https://graph.windows.net/contoso.com/directoryObjects?api-version=2013-04-05&$filter=isof('Microsoft.WindowsAzure.ActiveDirectory.User')%20or%20isof('Microsoft.WindowsAzure.ActiveDirectory.Group')%20or%20isof('Microsoft.WindowsAzure.ActiveDirectory.Contact')

Using GA Data Export API to Get All UA's

I am using the GA Data Export API to interact with Google Analytics and I'm making a lot of progress, I am using this URL Endpoint initially to pull all the profiles under an account:
https://www.google.com/analytics/feeds/accounts/default
This URL retrieves each GA ID (profile) and each UA. One thing I've realized is one account can contain multiple UAs and when this happens, this request pulls all profiles. We have a client who has about 115 profiles under like 10 different UAs, and the request takes about 30 seconds for the initial request (and then I believe it must be cached, because it speeds up considerably after this, but then the next day the same thing occurs).
Is there a way to get a list of UA's without pulling the profiles? This way I can query the UA specifically for the profiles instead of pulling each one.
Any advice on this would be really helpful!
Thanks
UPDATE: Here's some documentation on the specific call I am using right now:
http://code.google.com/apis/analytics/docs/gdata/gdataReferenceAccountFeed.html
UPDATE 1: I have found some interesting information in the docs
Once your application has verified
that the user has Analytics access,
its next step is to find out which
Analytics accounts the user has access
to. Remember, users can have access to
many different accounts, and within
them, many different profiles. For
this reason, your application cannot
access any report information without
first requesting the list of accounts
available to the user. The resulting
accounts feed returns that list, but
most importantly, the list also
contains the account profiles that the
user can view.
So this means that you have to use the default accounts call to get these back? Surely, somebody has had this issue before?
So apparently, you can query the account if you know the UA-ID, however there is no way to get back a list of only UA IDs.
One way you can do it is have the user enter their own UA ID instead of having them choose one; not as user-friendly as it could be but better than making the user wait 30 seconds!