We’re Still Here to Help (Even Over the Holidays!) - find out more here.
Forum Discussion
Dropbox scoped-app folder: Visibility of uploaded files to other users
We have a scoped-app, which mounts a folder owned by the app into my account. By piecing-together an invitation URL, we can mount it into other users' accounts as well (all are licensed under a team ...
Greg-DB
Dropbox Community Moderator
Dropbox Community ModeratorFrom your sample webhook payload, I see that your app is linked to the team itself, and so receives the list of all team members with changes. If you want to be notified for just one account, and don't actually need the connection to the entire team, you could instead link the app to a specific account instead of the whole team.
When using an "team scopes", the app is connected to the entire team. When not using any team scopes, the app is connected only to a particular account.
So, to do that, you could:
- Unlink the app from the team using this page. (This can only be done by a team admin.)
- Disable any team scopes using the "Permissions" tab on the app using the app's page on the App Console. (This can only be done by the app owner.)
- Reconnect the app, now without any team scopes, to the relevant account with the shared folder.
Two things to note with this setup though:
- This would notify you of changes in that particular account, whether or not that particular account was the one that made those changes; that is, the changes may be in a shared folder that account has, but performed by a different account. It sounds like this may be acceptable for your use case, but I'm highlighting it just in case.
- This would rely on that particular linked account remaining active. If that account is disabled, the integration would break.
Given how many different ways the account and webhooks can be configured and how difficult the flow is to understand, I'm more concerned at keeping the flow no more unintuitive than it already has to be. I don't want it to be very difficult to switch to auditing a different member if the member we're currently auditing leaves the company. So, I'm keeping the team scope, memoizing (i.e. caching into the process heap) the email-addresses that are associated with each of the member IDs as we're looking them up, and then filtering for a particular user configured via the environment. We have control over the member. We have control over the path.
Since we're only getting a list of the members that actually have specific access to the file/folder that is being touched, we just have to be careful, if we ever end-up enumerating one or more paths that might not include this audited, principal user, that we need to more intelligently manage the context (or else we'll fail when filtering for them and coming up empty).
About Dropbox API Support & Feedback
Find help with the Dropbox API from other developers.
