Child Item

Some questions about updated team space and the corresponding api change

Hi, we've received an email last week saying that "shared team space" is gonna be updated to "updated team space"

https://dropbox.tech/developers/api-updates-to-better-support-team-spaces

We've read carefully through the document, and we found that the change is gonna be done at 2024/01/31.

"please update your app to support these features and changes by January 31, 2024"

But according to our survey, the api change is tremendous. For example, the /2/files related api once can be called related to team root. But now, we can call them only relate to a team folder in "updated team space". Same applies to create_folder/move/delete/longpoll. We're developing synology dropbox cloudsync, and the code modification required is impossible to be done before 2024/01/31.

We want to ask several questions to make sure it can work.

1. For the user who used "shared team space" already, will they be forcelly updated to "updated team space" by 2024/01/31

->or will those users be kept as "shared team space"

->or can they decide whether to "update" or not

2. Does dropbox team really gonna be fully updated to "updated team space" by 2024/01/31. If so, can the deadline be extended? If the original api can't be used anymore, we have to migrate to the new one, our functions will break. Moreover, the oauth now is also a problem, our app doesn't have team permission yet. The change will have tremendous impact on our customers who already used it.

3. If you're gonna update the api, can we developers get a dropbox "updated team space" environment or app to test. We'll have to start supporting "updated team space" right now, if the deadline can't be extended.

4. What will happen to the "shared team space" user when they are "updated", will their "root namespace id" still be useful? According to your document, it seems like "root namespace id" is no longer supported. We can only use /2/teams to create/move/archive/delete team folders. So, the original "root namespace id" will be fully obsolete then?

5. Do you announce this anywhere? We haven't received the mails until last week. For other cloud providers, there should at least be 1 to 2 years for such migration. We have to update, test, and rolling release, it would take quite a while to support such tremendous modifications.

6. Is it true the /2/files can no longer be used under "team space root", but only under "a team folder"? If so, our syncing application architecture will have to re-write, and it will take absolutely more than 2 months.

7. Do we really have to use "business api" to sync team folders? I've seen that according to the document, we can only use /2/team api to manage team related folders. But our original app for the customers just don't have team permissions, we'll have to grant and update app permissions. Since we use the same app for dropbox personal and shared dropbox team, if we just update and grant the team permission for both kinds of dropbox configuration, will all our customers have to reauth?

Find more posts tagged with

API

Abuse

Comments

DB-Des

Hi there,

We appreciate your feedback, I’ll be sure to bring this up with the team for review.

To address some of your concerns:

Dropbox is not making changes to the behavior of the API for teams with the previous configurations. The API behaves differently for teams with the latest configuration however, and Dropbox plans to eventually migrate all teams to the latest configuration, which is why we've made this announcement. The deadline for this update is still set to be for 2024/01/31.
With the new configuration, every team member will have their own unique root_namespace_id. This ID can be obtained by calling /users/get_current_account, and should be set properly for each user the app is operating on as the value for Dropbox-Api-Path-Root.
Files and folders may not be added directly to the root of a team space using the /2/files endpoints. For folder creation, app can use /2/team/team_folder/create.
Team endpoints are Business Endpoints, thus team scopes will be needed to utilize these endpoints. Existing access tokens will retain only whatever scopes they were originally granted. If the app needs additional scopes for any particular account, it will need to prompt the user to process the app authorization flow again with the additional scopes. The user will then receive a new access token with the additional scopes granted.

Syno_dev

Hi, thank you for your reply.

I'm wondering what it means by "Dropbox plans to eventually migrate all teams to the latest configuration". Are the original teams with "shared team space" configurations still gonna be migrated to new "updated team space" configuration? Or will they just stay the same, and will never be updated to "updated team space", only the teams after 2024/01/31 will have new configurations?

If the old "shared team space" configuration will be updated to "updated team space", will the deadline also be 2024/01/31, or will it be extended?

Moreover, will we get access to "updated team space" account for development? If the deadline is surely 2024/01/31, it is almost impossible for us to finish migration before then. We'll have to just start as soon as possible.

DB-Des

Hi,

Are the original teams with "shared team space" configurations still gonna be migrated to new "updated team space" configuration? Or will they just stay the same, and will never be updated to "updated team space", only the teams after 2024/01/31 will have new configurations?

All existing teams will be migrated to the new team space configuration. Any newly-created teams will be defaulted to the new team space configuration.

If the old "shared team space" configuration will be updated to "updated team space", will the deadline also be 2024/01/31, or will it be extended?

The plan, currently, is still to have all existing teams migrated by 2024/01/31.

Moreover, will we get access to "updated team space" account for development? If the deadline is surely 2024/01/31, it is almost impossible for us to finish migration before then. We'll have to just start as soon as possible.

If you'd like to request a test team using the updated team space configuration, you can do so by following the instructions under "How do I test my application?" in the "Frequently asked questions" list here: https://www.dropbox.com/developers/support . Be sure to indicate why you are requesting that and specifically mention that you want a team with the updated team space configuration.

I hope you find this additional information helpful!

Syno_dev

Hi，thank you for your reply

Our application used to use team space root for syncing. However, if the configuration is going to change dramitically, we just can't use team space root any more. We'll have to sync from team folder, this will require us to modify bunch of apis.

Do you recommend other faster way to tune the architecture? If not, 2024/01/31 is just too urgent to adopt the change.

Our application will fail to sync then for all users with old shared team space configuration. Unless we have enough time to import reauth flow and change files api to teams api in order to create/rename/archive/delete team folders.

Syno_dev

Hi，

Our application used to use team space root for syncing. However, if the configuration is going to change dramitically after updated to "updated team space", we just can't use team space root any more. We'll have to sync from team folder, this will require us to modify bunch of apis.

Do you recommend other faster way to tune the architecture? If not, 2024/01/31 is just too urgent to adopt the change.

Greg-DB

Hi, thanks again for your feedback. I just wanted to jump in here to confirm that we've shared this with the team, including a request to extend the timeline. I can't promise if the timeline will be extended, but I'll be sure to follow up here if there's any news on that.

Also, in case it helps, I wanted to clarify a things:

Apps can and should continue to use the /2/files endpoints to work with files and folders; the exception is that accounts on teams with the updated team space can't create anything directly in the root of the team space, but they can continue to create and update things inside the team folders in the team space using the existing /2/files endpoints. For example, attempting to upload a file directly in the team space for an account on a team with the updated team space would fail with the existing path/no_write_permission error that is already used for other cases where the account does not have permission to upload a file in the specified location. Apps can upload files inside an existing team folder in the team space for an account on a team with the updated team space though.
In order to create new team folders, which would be placed in the team space for accounts on teams with the updated team space, an app would need to use /2/team/team_folder/create, which is the same way apps would already create team folders for teams without a team space.
For any kind of account, apps can still and should continue to get the root_namespace_id from /2/users/get_current_account. Likewise, apps can continue to use that value in the Dropbox-Api-Path-Root header, whether the account is on a team or not, and regardless of what configuration the team has. That will also work for accounts on teams with the updated team space.
The API will continue to work the same way for teams on the old configurations; there won't be any impact for teams before they are migrated to the updated team space.

tuiren

I finally came across this thread and find it quite resourceful. Three weeks ago, I purchased a Synology NAS exclusively to back up my team's Dropbox. Unfortunately, we never came around to achieve this as at the time of set-up the "Team Space Experience" integration was already broken and only the Personal folder being synced by the regular integration. After extensive discussions with both Dropbox and Synology Support, we concluded that our team had already been migrated to the updated Team Space experience, and Synology is uncertain about when Cloud Sync will support this updated API.

So it is interesting to read that

a) the migration will be happening to all teams over the coming weeks with no option to opt-out and

b) third-party app developers have received as little information about this API change as we have, which is none, up until the mid of November.

In our case, the impact extends beyond Synology Cloud Sync; our integrations with Airtable, Coda, and other third-party applications are currently broken, significantly affecting our day-to-day work.

Thus, I am using this thread to express my disappointment with how Dropbox has handled this situation. Not only were developers not given an early warning about the impending changes, but even before the deadline, accounts are being migrated and impacted by the API changes – all without any notice to us, the users. I urge Dropbox to improve their communication with both users and third-party developers.

Greg-DB

@tuiren Thanks for the feedback! I'll pass this along to the team.