I'm having trouble detecting sharing/permissions changes (e.g. shared link) for drive items. Couple of issues I'm running into:
Issue 1:
When Calling Delta:
returns very little information about a shared drive item
E.g:
"shared": {
"scope": "users"
}
If I require more information I may call the permissions api:
https://learn.microsoft.com/en-us/graph/api/resources/permission?view=graph-rest-1.0
So I thought I will try and expand permissions via $expand when calling delta e.g.:
https://graph.microsoft.com/v1.0/drives/b!2sYXPZYs-EWuKr_Zuq-PuJXgC5oupbFGksDDgkXp5Grd_x1DWcntTY1FyJEH9caq/root/delta?$expand=permissions
Unfortunately, am receiving the following error response:
{
"error": {
"code": "invalidRequest",
"message": "The request is malformed or incorrect.",
"innerError": {
"request-id": "ea0ed04a-a4f7-4fbe-a16e-61ff0770fcc0",
"date": "2019-07-29T19:31:37"
}
}
}
I am trying to avoid a "permission" call for each shared item. (I see no point in calling the API for each drive item). Any suggestions?
Issue 2:
I'm using "Notifications/Webhooks" to receive notifications about drive item changes. Notifications work well enough for modify, create, delete, etc...
However, I noticed that when there are "sharing/permission" changes, notifications are not sent.
Ideas? Is this a limitation? (Why is it not documented?).
Thank you.
I have an update and a partial answer:
It is possible to solve these two issues, but the solution is undocumented.
This may change in the future and Microsoft at some point may document it.
(If and when it is officially documented I'll update my answer).
If anyone is running into the same issue, the best course of action is to reach out to Microsoft through partnership channels and/or support.
Related
Extremely weird bug we’ve been facing today.
We have an iOS app which has updated a document using Realm SDK and I know it has been pushed successfully because I checked the forCurrentlyOutstandingWork session to confirm a 100% upload and also opened up another device to validate if it got the new updated information and it has.
The problem is even though Realm clients across multiple devices are showing the new updated information, the MongoDB doesn’t show the new updated information. It did update after 15 mins automatically but this issue happened to us multiple times today.
Has anybody else faced this issue and found a solution to it ? Or should this never happen and we need to report a bug ?
TIA
Edit:
Realm sync write log -
Logs:
[
"Upload message contained 1 changeset(s)",
"Integrating upload required conflict resolution to be performed on 0 of the changesets",
"Latest server version is now 249"
]
Partition:
1
Write Summary:
{
"Image": {
"updated": [
"612ce539db1dbb2655f6c723"
]
}
}
This was an issue in MongoDB/Realm. I reached out to the support and they resolved it by pushing an update on the 9th of September 2021.
The replication to MongoDB is asynchronous due to the fact that conflict resolution must be performed against incoming writes from MongoDB clients (which sync does not control), to prevent the situation where a write made to MongoDB and a write made by a Realm client pass right by each other and leave the two states inconsistent. Ideally, these writes should happen within a few milliseconds but some latency can occasionally occur (especially around server restarts), but we closely monitor this and are always looking to optimize this.
Engineer on the Sync Team
I moved applications insights from one resource group to another one. After moving I still can see availability tests in AI although I didn´t mark them for the move. Now I can´t do anything with them - disable, delete, edit.
When I try to delete test I get notification that availability test was deleted. But it was not. When I try to disable it I get notification: Failed to update availabity test. Updating availability test "webtest-appservice" failed with error:
{
"error": {
"code": "ResourceNotFound",
"message": "The Resource 'microsoft.insights/webtests/webtest-appservice-xxxxx-ain' under resource group 'xxx-rsg' was not found. For more details please go to https://aka.ms/ARMResourceNotFoundFix"
}
}
Is there a way to delete them?
Please try to use the Web Tests - Delete rest api.
On that page, there is a green button "Try it", just click it, and provide any necessary parameters.
I'm re-deploying an ARM template.
Whereas it worked last night (...) it's failing with:
{
"error": {
"code": "GatewayTimeout",
"message": "The gateway did not receive a response from 'Microsoft.Maps' within the specified time period."
}
}
This in turn causes the deployment to hang (for an hour+).
I'm pretty sure (but not 100%) that I didn't do a change that would cause this -- is this a Microsoft infrastructure problem?
If so, is there an url on Microsoft that provides information as to the status of services, and ETA as to when it would come back online?
If not, any way of getting more verbose error status report to ferret out the underlying cause (by me?). Thanks.
Turned out to be on the Azure Management API side of things, offline for a half day. The service remained up, but management/deployment apis down for a bit.
I used Graph API to add web hook for group conversations. Because I need to monitor conversations for all groups, I read the group list and add web hook for every group.
After 20-30 groups (The number will change for different accounts), Graph API begins return error:
{
"error": {
"code": "",
"message": "Server could not process subscription creation payload.",
"innerError": {
"request-id": "af7d109a-fb6c-4b41-9aa1-988fc21309ad",
"date": "2016-09-28T03:06:11"
}
}
}
It seems that Graph API will block after receive too many subscription request, is this right?
Then is there a way for me to monitor conversations for all group?
I don't think there's any way to accomplish this except to cycle through all the users and request conversation information one at a time. The drawback here is that it's generally a bad idea to request new information before an old request is finished (Microsoft will throttle your connection) so that limits you to about 2-3 requests/second at best. Depending on the size you're looking at, it may be several minutes between user refreshes.
This is based on my personal experience. I can't find any documentation that supports/denies this.
I am trying to implement some methods for a DDP API, for use with a C# remote client.
Now, I want to be able to track the connection to implement some type of persistent session, to this end, id hope to be able to use the session id given by DDP on connection, example:
{
"msg": "connected",
"session": "CmnXKZ34aqSnEqscR"
}
After reading the documentation, I see that inside meteor methods, I can access the current connection using "this.connection", however, I always get an undefined "this.connection".
Was it removed? If so, how can i access it now?
PS: I dont want to login as a user and access this.userId, since the app I want to create should not login, but actually just get a document id and do work associated with that, including changes to other collections, but all, regarding ONLY this id, and I dont want to have to include this id every time I call a function, since, this could possibly lead security problems if anyone can just send any id. The app would ideally do a simple login, then associate token details with his "session".
Changing from:
() => { this.connection; }
to:
function() { this.connection; }
solves the problem from me. Based on a comment in the accepted answer.
The C# client on github has a few bugs with it as it doesn't follow the DDP spec exactly. When you send commands to it to connect and run a call, it usually sends the '.call' too soon.
The method does work if you do it this way with this.connection on the server side Meteor method.
You need to make sure you send the method calls after you know that you are actually connected. This is what works at least with Meteor 0.8.2
I was using a file named ".next.js" to force meteor to use the newest unsupported javascript spec using a package.
Somehow this messed it up. Changed back to default javascript and it now works.
Thank you :)
init.coffee
Meteor.startup ->
# client init
if Meteor.isClient
Meteor.call "init"
methods.coffee
Meteor.methods
init: ->
console.log #connection.httpHeaders.host
it's that easy...