When fetching notebooks on my OneDrive account with
https://www.onenote.com/api/v1.0/notebooks
it always returns an empty list, even though Notebooks exist.
{
"#odata.context": "https://www.onenote.com/api/v1.0/$metadata#notebooks",
"value": []
}
I can successfully create new notebooks with POST and fetch them by ID so they do exist.
It seems that my account has a default notebook that is corrupt and since there is no way of setting the default notebook I am stuck and have no way of fixing my account. I even have physically deleted all notebooks from OneDrive, then created new ones but to no avail - GET /notebooks always returns an empty list.
How can I fix this?
Related
Bigsql is not able to read data from subdirectory like hive can by setting parameters.
set tblproperties (
"hive.input.dir.recursive" = "TRUE",
"hive.mapred.supports.subdirectories" = "TRUE",
"hive.supports.subdirectories" = "TRUE",
"mapred.input.dir.recursive" = "TRUE")
I tried adding above parameters into bigsql tableproperties but it's not able to read subdirectory data.
What parameters I need to set in bigsql to read subdirectory data?
As per my understanding, Bigsql only looks up for files in parent directory. It doesn't even bother checking sub-directories. It will display an empty table because it cannot read the data recursively.This feature is still under product improvement ideas with IBM product and engineering team.
I have enabled the Advanced Drive Service in an apps script. For a file in Google Drive, I need to set metadata properties that may already exist, so I am trying to use the update method of Drive.Properties. This method is supposed to "Update a property or add it if it doesn't exist." (See Properties: update.)
The following code fails silently (with nothing logged to the Logger and no properties added to the file). However, if I step through these same lines, I do see the catch block executed every time.
var fileId = '1jgoihblahblahblah' /* an existing file id */;
var property = {key: 'TestKey', value: 'TestValue', visibility: 'PUBLIC'}
try {
Drive.Properties.update(property, fileId, "TestKey");
} catch (e) {
Logger.log(e);
}
If I replace the call to update with this line:
Drive.Properties.insert(property, fileId);
... then the code works every time. The properties are written and are returned by calling Drive.Properties.list(fileId).
Testing the same values using the API explorer (with real values or the "TestKey" and "TestValue" examples above) always works correctly, so I don't think it's simply a matter of providing bad data. UPDATE: The API explorer is now returning an error "Property keys may only contain letters, numbers, and the characters .!#$%^&*()-_/" no matter what values I pass in. However, there are obviously no invalid characters in key names like "TestKey" and "Link" (which is one of the actual keys I am using).
1) How can I troubleshoot the error from within the Script editor? I can't yet figure out how to retrieve the error text, since update fails silently even without the try/catch.
2) I am using the syntax specified by the autocomplete prompt, since there's not actually any documentation for Apps Script syntax for advanced service.
Is that syntax correct? If so, am I doing something wrong that I'm not seeing?
This problem is irrelevant because despite its name, Drive.Properties.insert does the same thing.
See https://issuetracker.google.com/issues/36759642
Is there any scenario in which the Id field on a message could change?
We received a message at today (Thu, 19 Feb 2015 10:29:48 GMT +00:00) with an ID ending in 'MT80AAA='. However when trying to retrieve message details at a later time I get a 404 error with the message:
{ "error" : { "code": "ErrorItemNotFound", "message" : "The specified object was not found in the store." } }
When I do another request to get all messages from that inbox the same message appears however it has another ID ending in 'TwDlAAA='.
Both the message ID and the Attachment ID have been changed at some point from the first time receiving the message and now.
Is this a common occurrence? What could cause this? Or is it a bug?
It's not a bug, it's definitely a common occurrence with Exchange. Entry ID's aren't static, and can change in a number of scenarios. Common ones are moving the item (which is essentially a copy and delete operation, copy gets a new ID since it's a new item), or mailbox move (which may be applicable to your case).
Typically I would advise a strategy of optimistically storing the ID and using it first, since it will usually work. Then I'd recommend storing the record key and search key as a backup, so you could try searching for the item in the event the Id no longer works. However, the REST API doesn't expose these fields! So you'd have to make do with searching for the item based on whatever fields are important to you, which isn't ideal. I'll provide this feedback to our developers.
I'm using the drive change feed to find changes of files in Google Drive. I have been experiencing some inconsistency. I just tested using the API Explorer found here :
https://developers.google.com/drive/v2/reference/changes/list
On one user the largestChangeId returned was 1208, although when setting the startChangeId to 1208, the request returned 6 entries, including the change of 1208, and each other change being higher than 1208. I also have the flags includeDeleted = true, includeSubscribed = false.
I then tried on another user, the returned ID was 136023. When using this value with the same params as above Drive returned 0 entries, which I expected.
Then I tried on a third user, the returned ID was 8267. Then setting the call again with the same params as above Drive returned 1 entries, which had the same change id of 8267.
Note all three accounts are testing accounts on a test domain in which no documents are being modified or shared.
So three users three results making the same call. Is this expected or a better question, what should I expect when making this call. In the documentation it states : " Change ID to start listing changes from. (string)". When it says from and you are returned the highest ID I would expect 0 results to be returned.
Thanks.
Using the Box 1.0 REST API, I am trying to work with the functions in SOAP UI.
The API doc for get_managed_users with user_id=12345 (internal id retrieved with get_user_id call correctly) is returning all the users. The docs say that would be the case if you do not specify a user_id value. But my full command is: (Token and API key changed to protect the clueless)
https://www.box.com/api/1.0/rest?user_id=27360&auth_token=blahbalhblah1234&action=get_managed_users&api_key=someKeyYouShouldNotSee
Now I could work with the complete result list, but that won't scale as we get thousands of users into the system.
I can make a call with edit_managed_user, using the same user_id value and the change is reflected in the UI, and in the next get_managed_users call. Thus I do have the correct user_id value, I would so assume.
I tried testuser#gmail.com as the user_id value as well, and get the entire list back. This leads me to believe that somehow I am sending user_id wrong, but I just do not see it.
Any hints? Why, with what seems like a valid user_id value is it acting like it is absent or incorrect?
Most likely you have either called this method with an invalid user_id, or one that is not in your set of managed users. Can you double check that the user comes back in your list of already managed users?