Listing members in a team via Python

Presumably, user-wise, I'm looking for a method that load those member IDs. I think I saw a class called TeamDropbox or BusinessDropbox, but it doesn't seem to be mentioned in the current Sphinx documentation.

---

dsoprea wrote:

...

This differs from the folder-scoped app events, in that those have an 'accounts' list under the "list_folder" event/directive. ...

---

Hi dsoprea,

Yes, unfortunately documentation is a pain for Dropbox; and it's not only about API, it's the same for everything. 🤦🤷 Have you seen Dropbox official applications documentation? In this context the API documentation looks fine. 😁

You'll need to deduce what's there; no so difficult, I think. Just keep in mind that 'delta' part is obsolete and you will need to check only 'list_folder' content. They suppose to have the same information in different format (API v1 and API v2). As seems only API v2 is supplied as 2 copies; don't ask me why is it needed (API v1 wont recognize it, so it's meaningless to be there at all).

---

dsoprea wrote:

... I saw something somewhere that said that we should technically, probably, be receiving only one team ID at a time, but that under Dropbox's current architecture, we might receive more than one but that it's not predictable when. ...

---

Wherever you did read it, it's just not true and never has been. Presumably, multiple changes come together (of course, when as single change appears, it will be alone).

---

dsoprea wrote:

... I also saw something somewhere else that mentioned that we should be enumerating all users for each team in order to then enumerate a stored cursor for each? That doesn't seem right. Can you clarify?

...

---

No exactly; Not all users, only all denoted users. Of course, if by any chance all users have changed something then all of them. You should take in mind that a single change may appears in multiple member contexts as change - for all members that can see it (i.e. the same change might appears many times).

---

dsoprea wrote:

...

Meanwhile, I can't seem to even figure out which method to call to get the list of members for a given team ID ... There's too much of a divide between the RPC naming conventions and the Python calling conventions. ...

---

Any Dropbox SDK (including Python one) is just a wrapper of API, nothing more. The SDK just perform the technical work of perform HTTP calls for you (in some places may be added additional wrappers like save content to file, etc. - just for convenience). In general SDKs calls are one to one match to API ones. You can call regular methods to get particular team members, but you don't need to - all members that have something changed are listed too (their IDs actually).

Something else may confuse you. If I have to bet, you skipped to save users credentials (either team members or personal users) and now trying to access changes without proper credentials (relying only on the received IDs). If so, it's impossible! That would be a security break if it was possible (just imagine - you got access only by id, hmmm... 🤫). It's your responsibility to keep all data needed to trace what's changing when notification comes up and indexing all sets of such information by corresponding IDs. 😉 Here you can see some Python examples. They are for individual users, but I believe you can adapt them.

Hope this helps.

Yes. The clients are a thin wrapper for the API, but, nonetheless, it's what we're using to access the API and the naming is intractable, at least to an unfamiliar user. The brief examples given on the website don't mention any of the team/business semantics. They only work for non-team accounts.

---

dsoprea wrote:

... They only work for non-team accounts.

---

Yes, they are designed so. As seems it's difficult for you to adapt it!? 🧐

Try to change the line:

for account in json.loads(request.data)['list_folder']['accounts']:

...to something like:

teams = json.loads(request.data)['list_folder']['teams']
for team in teams:
    for account in teams[team]:

Everything else may stay the same (least for the test). 🙋

Hope this helps with the first steps of adaptation.

As I said before, it's your responsibility to keep all needed information!!! The only work for all those accountId is to be unique and so you be able index whatever you have stored before, nothing more. Of course you can use it whenever applicable. For the test (just to see how it's working) temporary remove all team related scopes, so only token (alone) will be enough. Issue tokens anew.

dsoprea I see Здравко already offered some helpful guidance, but to add a bit more information:

When using only "user scopes", an app will only be linked to specific accounts, and webhooks would notify only about specific accounts. You can find the documentation for that kind of webhooks here.

When using "team scopes", an app will be linked to entire teams, and webhooks would notify at the team level, as you saw. You can find the team-specific webhooks documentation here.

To call the API to get information about a particular team, you would use the team_get_info method. Note that that method does not take a team ID parameter as you have in your first comment. It takes no parameters and instead identifies the team based on the access token you use to make that call. Accordingly, you'll need to keep track of which access/refresh token is for which team.

To get the list of members for any given team, you would use team_members_list/team_members_list_continue.