Matt Stofka
My feedback
189 results found
-
14 votes
This is currently not planned, but we will consider with additional customer demand.
Matt Stofka
supported this idea
·
-
9 votesMatt Stofka
supported this idea
·
-
18 votesMatt Stofka
supported this idea
·
-
46 votesMatt Stofka
supported this idea
·
-
80 votesMatt Stofka
supported this idea
·
-
51 votesMatt Stofka
supported this idea
·
-
179 votesMatt Stofka
supported this idea
·
-
18 votes
We currently do not have this planned on our roadmap. Please keep the feedback & use cases coming to help us prioritize this in the future!
Matt Stofka
supported this idea
·
-
4 votesMatt Stofka
supported this idea
·
-
11 votes
Thanks for the feedback! This isn’t currently planned, but please keep the use cases coming to help us prioritize it.
Matt Stofka
supported this idea
·
-
399 votes
We understand the request, but unfortunately this is not on the near-term roadmap.
An error occurred while saving the comment -
66 votes
We understand the request, but unfortunately this is not on the near-term roadmap. We will be exploring improvements and enhancements to Tasks in the next 1-2 years and will take this into consideration when we do.
Matt Stofka
supported this idea
·
-
45 votesMatt Stofka
supported this idea
·
-
4 votes
Thank you for this request! I’d like to see additional customers with use cases for user-level collaboration restrictions.
Collaboration is a setting that is tied to content rather than users, and I’m not sure that we have evidence yet to make changes to that model.
Matt Stofka
supported this idea
·
-
16 votes
Thank you for the use case! Because there are a few ways to remove collaborators, it is unlikely we will prioritize this in our roadmap.
Matt Stofka
supported this idea
·
-
3 votesMatt Stofka
supported this idea
·
-
61 votesMatt Stofka
supported this idea
·
-
32 votesMatt Stofka
supported this idea
·
-
93 votesMatt Stofka
supported this idea
·
-
105 votesMatt Stofka
supported this idea
·
Breaking waterfall permissions could definitely be beneficial in some use cases but I agree with others that it could get really complicated, too.
I suppose I'd be happy with a folder setting that can be enabled by owners/co-owners to "Hide this folder and it's child content from External Collaborators" OR "....from non-Owners/Co-Owners."
This would effectively keep the folder structure the owner wants but everything in that branch of the tree would be invisible to external users or Editors and below, respectively. I suppose you could even allow the co-owner to select the permission levels from which to hide that part of the folder tree, i.e., instead of Editors and below, they could select the Viewer/Uploaders and below, Viewers and below, etc.
Enabling this would put a label on the folder and child content in both the web UI and Drive to indicate to the co-owner that this private setting was enabled.
You could also do this at the file level using the right-click context menu in Drive or the ellipses button in the web with a "Hide" or "Make Private" option, or via Classifications similar to setting a Confidential/Internal/Public label. It's important to have a visual label on the file indicating that it's hidden and it shouldn't be super easy to toggle on-and-off; there should at least be a message such as "Are you sure you want to disable this private setting? All of this content will now be visible to all collaborators!"
This hybrid approach still uses waterfall logic in order to hide everything in that branch of the folder tree so it wouldn't address the valid concern by Mark E regarding folder naming conventions in a Shared folder. I'm thinking that folder-level metadata with cascade could be used to apply a Client Name or Project name value to the parent folder (using Mark's example) and have that value show up in a metadata column next to all of the child folder/file names to provide the context for those similarly named shared folders. If you can ultimately take advantage of metadata attributes in Box Drive, too, then that client/project name could be shown in Drive as well.
I might read this back later and find some flaws in the approach I just offered, but hopefully there's something worthwhile in here. :-)