You might see that the Dropbox Community team have been busy working on some major updates to the Community itself! So, here is some info on what’s changed, what’s staying the same and what you can expect from the Dropbox Community overall.
Forum Discussion
lades
5 years agoExplorer | Level 4
File permissions in the shared folder
Hi, I have this case:
User A shares a folder to User B with edit rights and B didn't accept the shared folder yet.
In my application A opens the file from the shared folder, and provides the fi...
- 5 years ago
Apologies for the confusion! This is the expected behavior. Before user B "accepts" or "mounts" the shared folder, they will have the right to access to (hence the returned "access_type"), but won't actually be able to do so, since the content hasn't yet been added to their account.
You can detect this from the /2/sharing/get_file_metadata call for user B. In the response, if 'path_display' and 'path_lower' aren't set, that means that the file is not mounted in the user's account yet, so they can't interact with it. (They can mount it using the Dropbox web site, or via the API using /2/sharing/mount_folder.)
Greg-DB
5 years agoDropbox Staff
Apologies for the confusion! This is the expected behavior. Before user B "accepts" or "mounts" the shared folder, they will have the right to access to (hence the returned "access_type"), but won't actually be able to do so, since the content hasn't yet been added to their account.
You can detect this from the /2/sharing/get_file_metadata call for user B. In the response, if 'path_display' and 'path_lower' aren't set, that means that the file is not mounted in the user's account yet, so they can't interact with it. (They can mount it using the Dropbox web site, or via the API using /2/sharing/mount_folder.)
- lades5 years agoExplorer | Level 4
Greg-DB I'm facing another issue with the access rights:
I have a business account, get_file_metadata for a file from a team folder returns the tag `editor`, I assume the user has permissions to write (even both path_lower, patrh_display is set). However, upload rq is failing with the 409:
"error_summary": "path/no_write_permission/."
Please check the attached files for complete responses.
upload is performed with this header
Dropbox-API-Arg: {"path":"id:f1MRSe_xAMAAAAAAAAAAOQ","mode":{".tag":"overwrite"}}
- Greg-DB5 years agoDropbox Staff
lades I'll be happy to take a look, but I'll need some more information. Can you share the requests/responses for this? Please be sure to redact your access token though.
You mentioned "attached files" but I don't see anything attached.
Feel free to open an API ticket if you'd prefer to share privately. Thanks!
- lades5 years agoExplorer | Level 4
Greg-DB I found out what the problem was. When the header `Dropbox-API-Path-Root` is not specified, `get_file_metadata` is not returning the `path_lower` and `path_display` properties.
Dropbox-API-Path-Root: {".tag":"root","root":"63xxxxxx0"}
It all works fine (even the upload) if the `Dropbox-API-Path-Root` is defined.
About Discuss Dropbox Developer & API
Make connections with other developers
795 PostsLatest Activity: 2 days agoIf you need more help you can view your support options (expected response time for an email or ticket is 24 hours), or contact us on X or Facebook.
For more info on available support options for your Dropbox plan, see this article.
If you found the answer to your question in this Community thread, please 'like' the post to say thanks and to let us know it was useful!