Hi there! I am encountering a peculiar issue with the /2/files/search_v2 call in combination with team namespace ids, and I am not sure if this is a bug or the expected behaviour of the API. ...
See more...
Hi there! I am encountering a peculiar issue with the /2/files/search_v2 call in combination with team namespace ids, and I am not sure if this is a bug or the expected behaviour of the API. Consider the following team space configuration: /Team Dropbox (1)
/Team Dropbox/Sarah (2)
/Team Dropbox/Sarah/Documents
/Team Dropbox/Sarah/Documents/Example.doc
/Team Dropbox/John (3) When I make a /2/files/list_folder call using {"path":"/Documents"} with the Sarah account, I get the contents of the /Documents folder, including the file Example.doc. This is all perfectly fine. However, if I also make a call to /2/files/search_v2 using {"query":"Example","options":{"filename_only":true,"path":"/Documents"}} with the Sarah account, I get no results. After some testing I noticed that the /2/files/list_folder call implicitly uses the home folder of Sarah (home_namespace_id: 2) to list the content. However, the /2/files/search_v2 API call uses the root folder (root_namespace_id: 1). So the search call won't return any results in this case because the /Documents path provided isn't correct. To resolve this, I can use {"query":"Example","options":{"filename_only":true,"path":"/Sarah/Documents"}} where I add the Sarah home folder in the path. Or I can add the header Dropbox-API-Path-Root: {".tag":"namespace_id","namespace_id":"2"} to the original call. When I do this, the file Example.doc is returned in the search results. Why are the /files/list_folder and /files/search_v2 calls using a different root/home location? Or is it a bug and should the home_namespace_id (2) also be used implicitly for the /files/search_v2 call, as with the /files/list_folder call? Or am I missing something here?