"files stay here for the team" prevents me from moving files from team to personal folder

[msakten]

I - a TEAM ADMIN - cannot move files or folders from a team folder, to my personal (i.e. ADMIN) folder. I get an incredibly annoying message "files stay here for the team". How do I get around this?

[XionicFire]

In short... you summarized it perfectly 🤣

We pay for our Dropbox, were the master admin, if we want to nuke it, wipe it, reset it we should be able to, period, full stop.

Oh and wait until you find out you cannot delete any teams folders you made by mistake, you can only "archive" them, that definitely adds to the whole "we know better than you" mentality they got going

[Stacie2]

XionicFire - please say it louder for those in the background.  I wish we could get them to undo this update.  

[msakten]

Ok this is absolutely unacceptable and I'm furious @Jay please tell me this idiotic bug which is being presented as a "feature" will be addressed or I am cancelling my business account immediately. I just spent the whole day working offline - which involved moving files from team folders to my personal folder (because they were no longer needed in the team folder). Once my internet came back, dropbox MOVED THOSE FILES BACK TO THE TEAM FOLDERS WHILE I WAS RENDERING and completely messed up my renders and project. This is absolutely idiotic that DROPBOX OVERRIDES MY ACTIONS WITHOUT WARNING OR CONSULTING ME.

[mgambrell]

The original "killer app" of dropbox is that you could do whatever you wanted in explorer and dropbox would magically do the right thing, optimally, to sync it. I mention this for the benefit of newer dropbox engineers and project managers who seem to have forgotten that by engineering a brand new bug that is directly antithetical to the original mission. I'm sure there's a contingent over there that would love to jettison the filesystem integration finally so it's easier for them to manage our file-managing. You are hereby on notice: do. not.

[j2762mm]

Nothing frustrates me more as a business owner than wasting time. Now instead of just getting work done, I'm on the Dropbox forum dealing with this because my team is angry. 

Here we are with yet another Dropbox problem. People are saying they've been doing this for years and it worked fine, now Dropbox is telling us it's expected behaviour and they have no plans to change it? Seriously? Who makes these decisions? Is anybody listening?

[Romanovsky Law]

It is nice to hear my team is not the only one suffering from this idiotic update.  Unless this is fixed immediately, we're cancelling our subscription, as well.

[mgambrell]

OK, y'all. I came to complain about discovering I can no longer create new team folders via explorer, and ended up unraveling this whole mess. Since all you get from the dropbox "staff" here is gaslighting that brand new things have actually always been that way, I'll explain it the situation.

What's happened is that a system which was formerly organized around "folders in the team space" and "private user folders" has been "generalized" into two types of "top-level folders": "team folders" and "shared folders". Previously "private user folders" were very special, and "folders in the team space" were not: you could freely create and delete them. Today, we're finding we no longer can. It's because they're all special now, just as "private user folders" used to be. It seems our accounts were migrated instantaneously into the new paradigm in the following manner:

"private user folders" -> "folder shared to a user"

"folders in the team space" -> "team folder"

Note: I am using different terminology than the web client, because dropbox staff and dropbox docs do. But the web client uses this terminology (a poor decision, IMO)

Me and DB staff and DB docs call it "Top-Level" -> Web UI calls it "Team folder"

Me calls it "Team folder" -> Web UI calls it "Team folder, who can access: everyone at ORG"

Me calls it "Shared folder" -> Web UI calls it "Team folder, who can access: specific people"

Me calls it "something someone else shared with me" -> Web UI calls "Shared folder"

(I believe dropbox has dropped the ball in clear communication here by trying to be too-friendly for something that's fundamentally complex)

Flash forward to today.

Note, you cannot create top-level folders via explorer. That's because only dropbox proprietary API has the means to specify of the new types of top-level folders it is. Moreover creating is a complex operation because it's more than just syncing filesystem data now. Consider this scenario

1. There's a top-level team folder called FOO, but you don't have access

2. Therefore, FOO is not synced to your workstation

3. On your workstation, you create FOO

4. Wait, what? with what properties? Whaaaat? There's already a top-level foo with established properties. No, no, no. This can't be allowed.

Note, you cannot rename top-level folders via explorer, for similar reasons.

Note, you cannot put files in the top-level. That just doesn't make any sense. The top-level doesn't contain those any more. What about those of us that DID have files there? Was it ever allowed? I would suspect, so. I do notice that the "content" view on the web UI (aka "the top level") has a "show deleted files" option, which is not logical, since there aren't "files" here and there's nothing that can be deleted... unless... dropbox... did they... did they dare.... delete top-level files when "migrating" us to the new scheme? It would be logical but gutsy. Anyone know?

Note, you cannot move top-level folders anywhere else, via explorer OR web UI. Conceptually, that's because top-level folders by definition are sub-typed into one of the new categories; moving it would imply removing the categorization. Technically, it's more likely because a top-level folder isn't even a thing that can be put anywhere else but the top-level.

Note, you cannot delete top-level folders via explorer. If you try, it will undo itself after a couple of seconds (without an error message, as in the case of moving via explorer; this is an error and the client needs to be fixed). That's because there is no longer deleting of top-level folders, only "archiving". Deleting is for actual content. Archiving is for top-level folders, those new special things. The desktop client can't do this, I think, because someone at Dropbox wisely decided that the user needed to be educated about the difference between archiving and deleting, and only the dropbox proprietary tools can do that. In particular, you need to know that there's no UNDELETING those things.. per se... in case you went to hunt for deleted stuff.

Note, you cannot move top-level folders anywhere else, part 2: that may also be because it implies DELETING a top level folder (or removing it, in any sense), which is also forbidden.

Now I also want to consider another horrifyingly convoluted scenario: suppose you move a top-level folder via explorer, and dropbox does a workaround for us: they create the new subdirectory name, then move all the content sub-items, then archive the top-level directory. What happens... when... we... hit ctrl+z? Or, what happens if we hit ctrl+z AFTER another admin or someone otherwise on the web UI does something to the top-level content for the team, such as creating yet another top-level folder with the same name?

Everything falls apart. Everything falls apart because the workstation filesystem is no longer the organizational authority for the dropbox content. THAT SHIP HAS SAILED, Y'ALL. SAY GOODBYE.

We're still a bit lucky: the workstation filesystem is still the organizational authority for content items UNDER A TOP-LEVEL FOLDER. If that weren't the case, I'd be shopping for a new cloud drive right now.

Note, you cannot delete..er.. archive multiple top-level folders at once. There's not necessarily any logical reason for this, but I guess it could be a bit tricky to make edits to the properties on multiple things at once.

Note, you CAN "delete" top-level items from the non-admin dropbox web view... sometimes? I did delete one just now, which I created while testing earlier, but now the "Delete" and "Rename" options are disabled in a new test; this is what I expect: only the admin console should be able to do anything with top-level folders. Still.. this is puzzling.

A workaround for this madness for most of us shall be the following:

1. never, ever create top-level folders. Create a single top-level folder called "stuff". Now inside there you can freely operate. Of course you will need to update all your scripts and pathing muscle-memory.

2. do create top-level folders to simulate "private user folders", if dropbox isn't doing that for you already.

During the research of this, I discovered a quirk in the new paradigm. I accidentally archived a valuable team folder. When unarchiving it, it came back with zero members access. That is, the properties of the top-level folder did not unarchive along with the content. IMO this is a bug, but I guess there could be a complex reason for it (perhaps the set of users has changed since it was archived, and perhaps you've added a user that you do NOT want to have access to it, but yet you had it flagged as ALL, and now that new user would accidentally have access to it).

I do not like that the method for changing the properties on a top-level folder is called "share with dropbox". I think this is a too-friendly way to invite me to share it with outside users, but really I just want to control inside access. The established UX paradigms for this are to edit properties on something, not "share" it.

I suppose it's possible that for people who have NEVER USED DROPBOX BEFORE, the new design may make more sense, but we're confused by our decades of prior experience. At this point I think we need to forget everything we know and suffer through some basic introductory "how to dropbox" tutorial again.

For those of you who made it to the end: I'm sorry. I made it as simple as I could. But it's just not very simple.

[oz4]

I suddenly started having the same issue today. Extremely frustrating. I can delete or move the file out of dropbox to my desktop, but not to my personal folder as Admin. Ridiculous. The kind of thing that will make me seek an alternative service when the time comes.

[nada_dbx]

Hi thank you all for the feedback. We hear you loud and clear, and understand that this is a frustrating experience. We're working on reversing the change to allow you to move files in your team space to your personal folder. I will provide an update here when it is available.

[mgambrell]

@oz4 I think you will find that the top-level folder you "moved" out to your desktop has magically reappeared in dropbox.