We are aware of the issue with the badge emails resending to everyone, we apologise for the inconvenience - learn more here.
Forum Discussion
List of namespaces with no information
When I list the namespaces using "namespaces/list" and iterating through the namespaces using "files/list_folder[/continue]" I found that there are a few namespaces which I thought wouldn't be there, but they are shown.
i.e.
- Deleted team member's folder
- When a team member created a shared folder in his/her own Personal root folder, it is shown in the namespace.
- However, if we delete the member, I found that the folder's namespace still exist and I can still download the file via API calls but there is no way that we can access it via the main files UI nor viewable/searchable in the admin panel. I have found that only by calling "files/list_folder" in that namespace will I be able to know that the file still exists.
- Is there any way to permanently delete the file? Are we able to get metadata of who was the one who added the file/folder in the first place? I had to dig in the Activity page to see that there is a record of "Non member" with "Unspecified email" who added the file.
- I understand that I can call "sharing/get_folder_metadata" and look for "is_inside_team_folder" but since it can still be downloaded, how would the administrator get access to review this folder and delete it without resorting to any API calls? (Is there any difference in API calls between the new "team spaces" config and the old one?)
- A namespace called "new folder"
- I'm not sure if this is created by a previous user and left alone similarly to the case above or just a placeholder for new folders to have a temporary namespace. But since there's nothing inside and I cant get any data of when it's created, it looks like a random stub to me.
What I am trying to achieve in my code is this:
- List all the namespaces
- Traverse the namespaces and calling "files/list_folder" to list all the files in the Dropbox Business account.
- Merge the results.
- Display the files and folders of the dropbox as if they are on the web/desktop client itself.
- The files and folders from deleted team members pop up on my application, but when they visit the main web/desktop client, the users can't see the files and folders.
- Is there a better way to do what I want to achieve? Or at least be able to show on my UI that the file belongs to a deleted user/other reasons, and provide ways to delete it from the Dropbox account permanently?
Thanks!
Thanks! That helps clarify a bit. One important thing to note: just "deleting" a shared folder from an account does not destroy the namespace for that shared folder. ("Unsharing" the shared folder would.) Deleting a shared folder is just a way to "leave" the shared folder, i.e., to remove yourself as a member.
Anyway, if you're still seeing anything unexpected and want us to check on this for you specifically, please open an API ticket with the relevant API requests/responses. Make sure to redact the access token though.
- Greg-DB
Dropbox Staff
First, to clarify, do you mean that the deleted user's folder is still listed in the /2/team/namespaces/list response? I can't seem to reproduce that. Can you share the steps you're following to produce that?
Is there any way to permanently delete the file?
To operate on team owned content, you would use the "member file access" feature, e.g., to use the /2/files/delete_v2 and/or /2/files/permanently_delete endpoints. I can't say off hand if this will work in the particular scenario you're referring to though, as I'm not sure what the state of the team is that you're referring to, as above.
Are we able to get metadata of who was the one who added the file/folder in the first place?
Like the above, you would use the "member file access" feature, but for /2/files/list_revisions.
how would the administrator get access to review this folder and delete it without resorting to any API calls?
I can only speak to the API functionality. For help with non-API areas of the Dropbox product, please contact support.
Is there any difference in API calls between the new "team spaces" config and the old one?
The difference between teams using or not using the team space configuration is how the team is structured. It doesn't fundamentally change the API calls necessary, except that you may need to use the 'Dropbox-API-Path-Root' header in some situations where you wouldn't otherwise need to. I recommend reading the Namespace Guide for information on this. The Content Access Guide may also be helpful.
Is there a better way to do what I want to achieve?
If you're interested in specifically building a UI that lists contents from the user's perspective, you may want to start from /2/team/members/list[/continue] and listing the contents for each, as opposed to /2/team/namespaces/list[/continue], as the latter is more user-agnostic. (I.e., it's focused on giving distinct namespaces, not organized by user.) That's up to you of course though.
I don't remember exactly how the shared folder came into place, but from the activity log, it shows this:
Aug'18 Non member (Unspecified email) Added a file (File:"filepath") * No idea why the member has unspecified email but other deleted users have their emails
I did the following to try reproduce it:
- I have 2 users, 1 admin and 1 member
- Member creates a folder within member's personal space, adds a file and shares it with the admin
- Admin accepts the invite and added to their personal space
- Admin deletes the shared folder from their personal space
- Admin deletes the member account
- Admin permanently deleted the deleted folder
I'm not sure if the "permanently delete" action triggered an update, but once I did it, some of the namespaces were corrected, and the particular shared folder's namespace is gone.
I'm not sure how I would be able to have you take a look at the state of my deveolpment dropbox business account without giving you an access token. Please advise on further steps.
- Greg-DB
Thanks! That helps clarify a bit. One important thing to note: just "deleting" a shared folder from an account does not destroy the namespace for that shared folder. ("Unsharing" the shared folder would.) Deleting a shared folder is just a way to "leave" the shared folder, i.e., to remove yourself as a member.
Anyway, if you're still seeing anything unexpected and want us to check on this for you specifically, please open an API ticket with the relevant API requests/responses. Make sure to redact the access token though.
About Dropbox API Support & Feedback
Find help with the Dropbox API from other developers.
