On-prem server Bitbucket 6.10.
Referring to the API for adding default reviewers for a project.
POST Request:
https://git.company.net/rest/default-reviewers/1.0/projects/test-project/condition
Body:
{"sourceMatcher":{"id":"any","type":{"id":"ANY_REF"}}, "targetMatcher":{"id":"any","type":{"id":"ANY_REF"}}, "reviewers":[{"name": "p950a", "slug": "p950a", "id": 56111},{"name": "p950h", "slug": "p950h", "id": 45222}], "requiredApprovals":"0"}
It seems it's mandatory to pass "id" for each reviewer - "slug", "name" don't seem to work. I get the following error if "id" is excluded.
{
"errors": [
{
"context": null,
"message": "No user exists for identifier -1.",
"exceptionName": "com.atlassian.bitbucket.validation.ArgumentValidationException"
}
]
}
It's quite inefficient and tedious to retrieve IDs for several users, store them and then again iterate over that list to pass here. Is there a better way to do this or am I missing something?
Related
So I've been trying to get email addresses of people that have access to certain files in a Sharepoint document library of a site through the use of the Microsoft Graph API. Below is an example of how my permission object looks like, which is retrieved from https://graph.microsoft.com/v1.0/sites/<site id>/drives/<drive id>/items/<item id>/permissions.
{
"#odata.context": "https://graph.microsoft.com/v1.0/$metadata#sites('...')/drives('...')/items('...')/permissions",
"value": [
{
"id": "...",
"roles": ["owner"],
"grantedTo": { "user": { "displayName": "testsite - Eigenaars" } },
"inheritedFrom": {}
},
{
"id": "...",
"roles": ["read"],
"grantedTo": { "user": {"displayName": "testsite - Bezoekers"} },
"inheritedFrom": {}
},
{
"id": "...",
"roles": ["write"],
"grantedTo": { "user": { "displayName": "testsite - Leden" } },
"inheritedFrom": {}
},
{
"id": "...",
"roles": [
"write"
],
"grantedToV2": {
"siteGroup": {
"displayName": "Developers",
"id": "120",
"loginName": "Developers"
}
},
"grantedTo": {
"user": {
"displayName": "Developers"
}
},
"inheritedFrom": {}
},
{
"id": "...",
"roles": ["owner"],
"grantedTo": {
"user": {
"email": "testsite#mysharepoint",
"id": "uuid",
"displayName": "testsite - Eigenaars"
}
},
"inheritedFrom": {}
}
]
}
I assume the testsite in the displayName property is a group name (probably the group that belongs to the site the file resides in), but I have seen cases where I can't find this group name in the groups retrieved from the /groups endpoint in the Graph API.
You can also see the group Developers, which I haven't managed to find in the full group list retrieved from /groups.
The documentation around this is quite vague and unclear to me. Somewhere I read that this lack of data could be due to authentication scopes, but I have "god mode" administrator rights in this Sharepoint environment, so that would seem strange to me.
My main goal is to be able to get all users that have access to a specific file.
Thanks in advance!
1. I assume the testsite in the displayName property is a group name, but I have seen cases where I can't find this group name in the groups retrieved from the /groups endpoint in the Graph API.
This is because as per Drive Item Permission >> Identity Set >> Identity resource type Quoting
The identity's display name. Note that this may not always be available or up to date. For example, if a user changes their display name, the API may show the new value in a future response, but the items associated with the user won't show up as having changed when using
This can explain why sometimes you don't see the group name in your groups.
I suggest you use the id.
2. My main goal is to be able to get all users that have access to a specific file.
Do you have any users that appear on the Has Access section of the drive item on sharepoint? For users you should be able to get permissions and use the ids to Get directoryObject using the id values from grantedToIdentitiesV2 or grantedToV2 which will return odate type.
GET https://graph.microsoft.com/v1.0/directoryObjects/{id}?$select=id
{
"#odata.context": "https://graph.microsoft.com/v1.0/$metadata#directoryObjects(id)/$entity",
"#odata.type": "#microsoft.graph.group or user or application",
"id": "id"
}
For groups, the users would be the members of the group.
I am trying to create the schema for Message API
As per the documentation, the sample response properties for reaction provided are below
Documentation sample response
"reactions": [
{
"reactionType": "like",
"createdDateTime": "2019-01-21T19:55:51.893Z",
"user": {
"application": null,
"device": null,
"conversation": null,
"user": {
"id": "e1ecb745-c10f-40af-a9d4-cab946c80ac7",
"displayName": null,
"userIdentityType": "aadUser"
}
}
}
]
From the documentation user is Identity type identity set
Identity is of type:
{
"displayName": "string",
"id": "string",
"tenantId": "string",
"thumbnails": { "#odata.type": "microsoft.graph.thumbnailSet" }
}
From the sample response as well as the response from endpoint, tenantId is not present.
There is a difference in sample response/actual endpoint response and documented properties:
The one with tenantId or one without tenantId.
The user is 1 level as per property documentation but as per actual response and sample response user property has user with in.
What is the correct schema of reaction property that we should consider, because we see variation in documentation vs actual response ?
ok, I think I understand - you're just asking what you should be coding for / expecting, when you query the api. It looks to me like the first link you've posted is the more correct, but you can verify this by using the Graph Explorer. This response does NOT bring back "tenantId", but you haven't explained if you -need- tenantId. If so, there are other ways to get it.
#KritikaVohra, Consider the response that you receive from the https://graph.microsoft.com/beta/teams/{id}/channels/{id}/messages. You don't need tenant id here. in case in conversation if you need it, you can use it from turnContext.
When trying to filter for a custom created schema extension:
https://graph.microsoft.com/v1.0/me/events?$filter=(<schemaId>/<key> eq '<value>')
the error message we get is:
"message": "Could not find a property named 'e2_<ourTenantID>_<schemaId>' on type 'Microsoft.OutlookServices.Event'"
The problem is that before performing search, the API prepends tenantID to schema ID, thus failing to recognize the property. It seems that graph API performs search using their own internal schema ID.
Interesting thing is, that when searching for a non-existing schema, the tenantID is not added.
The problem persists when testing to filter messages, events and contacts.
Our schema extension creation JSON:
{
"description": "Extension to help avoid duplicates",
"targetTypes": [
"Contact",
"Message",
"Event"
],
"properties": [
{
"name": "UniqueId",
"type": "String"
}
],
"status": "InDevelopment",
"owner": "<appID>",
"id": "<name>",
"#odata.type": "#microsoft.graph.ComplexExtensionValue"
}
I'm upgrading my application from SurveyMonkey's API v2 to v3 and using the liogi/surveymonkey-api-v3 library to wrap around my API calls and am not sure if I'm understanding how respondent info is being handled now.
The v2 endpoint POST /surveys/get_respondent_list would return data.respondents[_].email, .first_name, and .last_name, but its v3 equivalent doesn't.
Is it the case that with the API v3, this data can only be pulled from pages[_].questions[_].answers[_].text?
I hope not, because that makes pulling respondent names and email addresses way more complicated and seemingly necessitates knowing the question IDs that correspond to the correct fields for every survey. Am I misinterpreting the API, or has that "get respondent's email address" feature been gutted?
The email, first_name, and last_name are now all in the contact data in the metadata field provided in the response body when fetching a response.
So a request like:
GET /v3/surveys/<survey_id>/responses/<response_id>
will return something like this in the body:
{
...
"metadata": {
"contact": {
"first_name": {
"type": "string",
"value": "Test"
},
"last_name": {
"type": "string",
"value": "Example"
},
"email": {
"type": "string",
"value": "test#example.com"
}
}
}
...
}
Those 3 fields will also show up in the same place for the bulk responses endpoint.
I'm trying to create a planner plan using Graph as per http://graph.microsoft.io/en-us/docs/api-reference/beta/api/user_post_plans
but I'm consistently getting the following BadRequest response:
"error": {
"code": "BadRequest",
"message": "Write requests are only supported on contained entities",
"innerError": {
"request-id": "eae08944-6f47-477e-9950-ade31c473dd7",
"date": "2016-03-07T11:59:04"
}
As per the docs I'm POSTing to https://graph.microsoft.com/beta/me/plans with the following body:
"createdBy": "<my uuid>",
"owner": "<a previously generated group uuid>",
"title": "Blah Plan"
with no luck. The previously generated group looks like the following:
{
"id": "<uuid>",
"classification": null,
"createdDateTime": "2016-03-07T09:53:26Z",
"description": "Int Test",
"displayName": "Int Test",
"groupTypes": [
"Unified"
],
"mail": "<email_address>",
"mailEnabled": true,
"mailNickname": "IntTest",
"onPremisesLastSyncDateTime": null,
"onPremisesSecurityIdentifier": null,
"onPremisesSyncEnabled": null,
"proxyAddresses": [
"SMTP:<email_address>"
],
"renewedDateTime": "2016-03-07T09:53:26Z",
"securityEnabled": false,
"visibility": "Public"
}
I've tried various combinations of request bodies. With and without createdBy values. With and without owner values. Nothing seems to work.
Any ideas where I'm going wrong? The error is consistent across my integration tests as well as through the graph explorer.
Thanks
As Sriram mentioned, this was a documentation bug. It has just been fixed. The updated URL is: https://graph.microsoft.io/en-us/docs/api-reference/beta/api/plan_post_plans
The issue was in which endpoint to call to create a plan. You should call "/plans" instead of "/me/plans". You should also be aware that some of the data you are passing in is read-only. You should not include "createdBy" because this is a read-only property set by the service, not you. The plan resource documentation will show you all of the properties that can be set on a plan.
The last thing to keep in mind is that you can only have one plan per group. If you try to make a second plan, you'll receive an error about this from the API.
In Juli 2017 the API was modified and released. The new endpoint for creating a plan now is:
https://graph.microsoft.com/v1.0/planner/plans
with a request body e.g. like this:
{
"owner": "<group-id>",
"title": "my plan title"
}
where <group-id> must be the id of a previously created group.
Apologies for the confusion here. The documentation has a bug will be updated shortly. To create a plan, please ensure that a group is created, and the user is member of group. Then create the plan with owner set to group id, and createdBy set to user id.
For this issue, can you please try following the below steps exactly?
Create a unified group
Add user to be member of unified group
Create plan by sending {“owner”: group-id, “title”: string} - do not send "createdBy" field since it's a read-only field
For adding tasks to buckets, it should work just fine if you sent
{“planId”: plan-id, “bucketId”: bucket-id, “title”: string}
If this still doesn't work, feel free to reach out to me at lixian#microsoft.com.
Thanks,
Sean