I want to fetch the events related to my dropbox like I can see here , means I want to get when a particular file is added, changed, moved, deleted or renamed and by which user.
I have looked into the Webhooks docs. The webhook docs states the the response it sends to the callback url contails the userids, with which I can update the directory listing based on the webhook response for the user by calling the /delta.
But with it I cannot tell if there is an operation made for a file like a particular file has been renamed or deleted as since if I rename a file fro abc to xyz. If I get a response then I will look for the changes related to the file xyz which I will not find in my existing database so logically I will be making the events as deleted abc and added xyz, where as the reality is renamed abc to xyz.
It will be really grateful if you can help me regarding this.
There's no real way to detect a rename (versus a delete and an add) via the Dropbox API. You can use heuristics (like whether the new file has the same contents as the old file and was created around the same time as the old file was deleted), but those are just going to be guesses with varying levels of accuracy.
Also, there's currently no way via the API to see which user modified a file in a shared folder.
UPDATE: The Core API now includes (in beta) the ability to see who last modified a file in a shared folder. See https://www.dropbox.com/developers/blog/101/new-in-beta-shared-folder-metadata.
A file rename is reported as DeletedMetadata followed by a FileMetadata for the file.
What is annoying is that DeletedMetadata do not contain the file .id attribute, only .name and .path, while FileMetadata include all attributes (.id same as before any deletions/renames, updated .name and .path).
So you should have a local mapping connecting names/paths and IDs in order to know which file got deleted (when only DeletedMetadata is received) or renamed (when both DeletedMetadata and FileMetadata are received).
Related
We store uploaded files in Documentum and in the event someone uploads files with the same name, we would like to be able to retrieve the correct file using the Rest API.
We store metadata (filename, etc.) in the database as part of a queue of work. So a user will go in and pick the next item in the queue (in this case look at the uploaded file). Currently we look up using the filename and return the first file which is not ideal.
I know you get the Document back (including object id) upon upload, and I was thinking about storing that along with the other metadata, and we can compare that, but I stumbled across an article suggesting this was a bad idea.
I'm new to Documentum, so how do others manage this?
The referenced article is correct. Using of r_object_id for external references is not good idea especially because of the possible future migration. Because r_object_id contains the docbase ID and when you migrate into a new docbase then all documents will have different r_object_id.
You can solve it by adding of a custom attribute to the document type, where you can store copy of the r_object_id value (can be implemented by TBO) or generate your own ID (it can be also implemented by TBO or DB sequence), when the attribute is not filled in yet. Then you can use this value as a unique reference to that uploaded document.
And when you migrate into another docbase in the future r_object_id will change but value of that custom attribute will still remain the same.
I'm trying to build a sample app in Wit.AI, with a lot of entity values and expressions. Thus, to create that app manually is not an option.
I've tried their "import" feature, but it seems it doesn't work very well or it might be very capricious about the zip. The things I've done and nothing gave a result:
Download a zip from another app in my account
Change the zip command in order to work for the new app
The changed files are expressions.json and a single file in the entities folder, describing an user-defined entity.
Zip the whole folder in order to preserve the structure of the ZIP
Nevertheless how many approaches I've tried (format the JSON and etc.) nothing worked! The server returns 400 Bad Request response.
Further, I've tried with their Web API, but to no avail again. When I'm updating the values of an entity the server responses with Success, the response doesn't contain the new values...
I've checked this article Error importing app from backup on wit.ai and many others as well as some issues on GitHub, but again...nothing helped ;)
So, if anyone could help on that...He/she gets a beer! :)
When you create a new app, you can simply upload the the zip file in Import your app from a backup, and create the new app.
To be sure to not include any redundant files in the app zip file, it is important to use the following to zip app files:
zip AppName.zip AppName/app.json AppName/entities/*.json AppName/expressions.json
and upload AppName.zip.
Note that, the name of new app, zip file, and app name in app.json file, all should be the same (here AppName).
I've setup the 3 item webhooks (create, update & delete) so I can sync and log some data on an external service.
They all seem to work as inteded, except for the item.update, which doesn't trigger when a file is uploaded. It triggers when I change another field, but not when only uploading a file and then saving.
I've searched around but haven't found anything on the problem. Is it a setting I'm missing or doesn't the Podio API support this usecase?
In Podio an item and a file are two distinct entities. The behavior you are experiencing is as expected. The item update webhook will only be called when attributes of the item are changed; not when a file is uploaded and associated with an item. If you want to execute a webhook on a file update you'll have to set that up as well.
see 'file.change' hook
https://developers.podio.com/doc/hooks
Base on their document http://blog.fineuploader.com/2013/01/25/delete-an-uploaded-file-in-3-3/, there is the UUID of the file to be deleted sent server with teh delte request.
But I have been trying the whole day and i cant get it to work.
For example here is a UUID of a file "1a2c636f-04f0-48c3-956f-22274a93b82f", i don't know how to use this to delete a the file. Should it be decrypted with some form of function first.
This might be a simply thing, but i don't know how to do it.
Thank you for your help in advance.
The UUID for a file is passed along with each request. You must associate this UUID with the actual file server-side. When the DELETE request comes in, find the file associated with the passed UUID, delete it, and return a 200 response.
Looking at the server-side readme again, I realize that the presence of this parameter in each request is probably not documented very well. I just updated the documentation to add another reference to this parameter.
Let's say my RESTful API deals with files and folders. With it, I can create and edit both files and folders.
A file can belong to a folder. So let's say I want to move a file to a different folder. Which would be most appropriate, according to spec and/or what is most common?
POST to /file/:id, sending the new folder's id, changing the value
for just folder_id, keeping all other attributes untouched. The API
method only updates folder_id.
POST to /file/:id/location, sending
the new folder's id.
This isn't really a straightforward answer but I guess the question I would ask myself is: should the move file action be more appropriate for a file resource or a folder resource to handle. I wouldn't worry too much about the URI structure until I had an answer to the question.
The move action touches three resources; the file, the original folder and the destination folder. A client would need to know at least the file URI & the destination folder URI since the original folder can be inferred. I can see a case being made for both approaches. The file resource representation (the contents of the POST) could indicate a new destination folder as a value which is assumed to empty if no move is required. A folder resource could assume that a file representation contained in a POST implies moving that file to the folder. Whichever approach makes the most sense for your business process is the one I would go with.