Break waterfall permissions
Allow for restricted permissions within a shared folder (so permissions are not inherited from the parent folder)
We understand the request, but unfortunately this is not on the near-term roadmap.
-
Anonymous commented
My house has a lock on the front door and I can have a lock on a bedroom too. I'm not too certain why this a hill to die on.
-
AdminAnonymous (Admin, Box) commented
Today, there is a LOT of confusion about this...
(Scenario A) Notably, customers know that a user at the subfolder can't have LOWER permissions than the same user at the parent folder (e.g. if they own the folder, it would be odd for them to not also have owner access to everything inside of that folder).
(Scenario B) BUT... many customers want to give a user at the subfolder HIGHER permissions than the same user at the parent folder (e.g. Lisa has Editor access for HR benefits subfolder, but only Viewer access for HR parent folder... analogously, for a hotel you have "Editor" access to the "subfolder" room you are given a room key to, but you don't have access to sleep in the hotel lobby that everybody has "Viewer" access to).
Today, Scenario B is possible through proactively giving the person higher permissions at the subfolder (e.g. Editor) and then lower permissions at the parent folder (e.g. Viewer), but a lot of customers don't do this proactively, because they start by giving the person access at the parent folder, and they want to give the user permissions on the subfolder retroactively (e.g. maybe the subfolder didn't exist when the parent folder was created). When they change permissions at the subfolder retroactively, they get the error "Change Role for Parent Folder," regardless of if they are giving the user higher or lower permissions at the subfolder.
Giving customers the option to retroactively give users higher permissions at the subfolder would be immensely valuable.....
-
Anonymous commented
This would indeed be a useful feature.
-
Anonymous commented
This needs to be added to your near-term roadmap.
-
Anonymous commented
This functionality is definitely required. Box needs to do something to add this functionality,
-
Anonymous commented
This needs to be added to your near-term roadmap.
-
Anonymous commented
Why doesn't Box offer this feature, is it an intentional "security" safeguard. Seems pretty silly otherwise???
-
Anonymous commented
This should be an obvious feature of removing access to an individual subfolder. My staff have access to the entire drive and only require a few folders to be restricted. Please make this possible immediately.
-
Anonymous commented
We recently hit a problem where someone was securing what they considered to be their own sub-folder and removed access to hundreds of people from that sub-folder. But because of the upwards waterfall problem, no-one in the organisation could access anything at all. It was a nightmare to restore all the required accesses. Please provide a means to secure sub folders.
-
Anonymous commented
Being able to organize projects by the project and not by active external collaborator sets would be a huge win. It would simplify and flatten folder organization and I would not have to jungle folders around and redo folder permissions based around external collaborator groups, instead I could just make singular updates when collaborators change scope or status.
-
Anonymous commented
We're switching our company to Dropbox because of this
-
Anonymous commented
I agree that watefalls only go downwards. Please introduce this
-
Anonymous commented
I want to be able to disconnect the inherited access - to allow me to remove access without affecting the other folders
-
Anonymous commented
Unfortunately, this may be an overall deal-breaker for us.
-
Anonymous commented
Please add this feature, It is much needed.
-
Anonymous commented
Please Please Please do this. We did indeed follow instructions to "plan our structure carefully". The end result is that many of our staff have 40 or more folders where their content might be located. Those folders may or may not be named in a way that is meaningful to each employee, and no one can tell another employee where a particular file or folder might be located, because everyone sees the structure differently. Waterfall is a nightmare.
-
Anonymous commented
I'm also trying to allow a collaborator to see everything in a top level folder (as a Viewer) -- but to only be able to edit items in a subfolder (as an Editor). Having to put the subfolder at the same folder as the project itself in order to accomplish this complicates teamwork substantially.
It's plainly logical to allow users lower down to have more rights. Our internal corporate servers function this way -- we can't change things at the top level, but we have complete rights in certain folders lower down. I expect most corporate servers work this way.
I know our company has been considering contracting with Box to provide full remote server services. But we certainly won't be able to unless top level folders can be tightly controlled, with subfolders that allow the same users more rights.
Please rectify this. "Waterfalls" only fall down -- they don't also travel upwards.
-
David Grenkevich commented
Box is the only system that I have ever encountered that has permission inheritance work up as well as down. Typically, a "child" inherits from the "parent", and not the other way around. This behavior makes it difficult to share files with collaborators without giving them more permissions than they need. E.g., We want everyone to have View rights on a Budget folder, but Edit rights only in the current subfolder. But when we make someone an Editor on the subfolder, they are promoted to an Editor on the parent folder, and every other subfolder. I have brought up this behavior to tech support several times and each time I'm told "that's just the way it works". The workaround of breaking a subfolder out isn't a very efficient solution.
-
S. Newman commented
If I understand this correctly, this is something that would make things easier in my company with our current folder structure templates that we (try to) use.
-
Anonymous commented
You could keep the waterfall permission structure and introduce a feature, to restrict users/groups from files/folders, that would have precedence.
There are already classifications that can override the main permissions, so it should not be so complicated to add a function - restrict, that would be used exactly the same as the share function.