481
SPACES - more granular permissions
in progress
Iann Miller
I would like to be able to assign permissions at the SPACE level.
For example:
TECH SPACE - TechServices Google Group has write access. Principals Google Group has COMMENT access. Cabinet Google Group has READ access.
That way, every newly created project has 99% of the correct permissions going forward as we create them and we don't have to add 20 people to every new Project.
Log In
Louise Ewing
in progress
Hey Everyone! Quick update to share we are currently working on this!
T
TRENDUP
very welcome resources. please implement as soon as possible
Louise Ewing
in progress
Hey Everyone! Quick update to share we are currently working on this!
R
Rob Riccio
Louise Ewing Here's how to bring some logic to permissions management with inheritance:
1st, Allow setting Granular permissions at the Space Level, even the Workspace level.
2nd, If an object is set to 'Public'; share w: [The Parent Level], then it inherits constantly syncing permissions from the parent object.
e.g. Space: Share w. [Workspace], Folder : Share w. [Space], List: Share w. [Folder], etc. = Inherit & Sync from parent.
3rd, If an object is set to 'Private'; then it does NOT inherit, and you manage the permissions for that object individually by user & permission level. Changes to parents do not override these object permissions.
You can already manage permissions granularly by setting anything to private and just choosing who can do what. Then no override by parent permission changes is possible. So 'public' objects don't need to
ALSO
carry this functionality to protect against undesirable overrides; thus removing the option of INTENTIONAL overrides.As it exists, there IS NO option for choosing between inherit & sync vs. not; which is really unworkable at the Enterprise level.
Florian Schardt
A feature to manage permissions on a space level would help us to improve the stability of our spaces.
Certain members ("space admins") should be allowed to add/edit custom fields and task statuses (e.g. create a new custom field or create a new status). However they should not be allowed to do so in other spaces.
Currently we sometimes have issues of custom fields disappearing. As there is no history of custom field editing, we do not know who has done the change. We cannot completely revoke the permission to edit custom fields at all, because users should be allowed to handle those in their spaces.
Louise Ewing
Hi Everyone!
While we are still very much looking into more granular Space permissions we have been laser focused on our commitment to quality as our top priority. We will share additional updates on this request as they become available.
C
Catherine Opina
From a user:
Sure...the idea is a Space is likely one Customer...for example Dr. Scholl's is one of my customers and I run Web Development and SEO for their company but I also have some teams I manage on a project basis for ERP items. Because these are different functions...they have different Folders and different individuals that need to work in those folders. So I would want to be able to make an Admin for say the Web Dev Folder so they can add members and guests as needed to manage the Web Dev work, but then separately add an Admin for the SEO folder who will be adding their own members and guests. Two different functions, two different teams that do not overlap.
I am an agency so each Space is a customer and each folder is a service...each service has a different manager and team and those managers and teams may not be the same for each Space :) as depending on the platform of the customer...I may use different teams to handle the development.
Jessica Tucci (JTUC)
Some suggestions/thoughts after trying to work with permssions in clickup:
SPACE LEVEL PERMISSIONS NEED IMPROVEMENT:
- allow choosing the default access level for "Everyone on clickup" for each space (i.e. none, view only, comment, edit, full), this would be inherited down to all subfolders, lists under that space (unless overwritten by something explicitly set underneath that hierarchy)
-allow for adding teams/users at the space level which would overwrite the default access level and be used instead (again this access should be default trickle down to everything created under the space unless explicitly shared at a different permission level)
The default setting for new spaces should be something that is configurable on the overall workspace settings level. i.e. I want by default FULL or I want by default NONE should be a choice in the space settings by admin/owners).
MORE OPTIONS FOR PERMISSION LEVELS:
- I like the idea of having custom roles you can create which allows you to have users shared with just the right level of actions allowed based on your use case (rather than cramming things into different access levels that may or may not have exactly the combo of permissions/actions needed)
MORE CONTROL OVER PERMISSIONS TO EDIT SPECIFIC FIELDS
- for example I would like to allow someone to only be able to come in and view tasks and edit a specific field, but not change tasks statuses or other fields, today this is not possible. (a toggle for each field that can indicate it can not be edited unless you have full permission would help a lot)
PERMISSIONS FOR VIEWS:
- I would like to have options for sharing specific views under a list with different permission levels. Currently there is only private (only me) or public everyone on the list level. It would be great to have the same options at the view level as we do at the list level.
M
Matthew Edmunds
My frustration is with the private v public space settings. I create a space and make it private and include my users. but when a list or folder is added in the space, by default it becomes public?? Why doe it not follow the hierarchy of the space to which it belongs. Now I have to go back into each list and folder and individually make them private again and invite again the correct users one y one. Very wierd and frustrating.
I
Igor Afanasjev
Truthfully, I would create a separate option in settings with custom roles and check box list of different capability options where admin can manually modify what access each role will have. Also would be nice to have an option to prevent main task name only editing completely, so no one can edit the name even on accident, regardless of access level. Option to create subtasks with edit role permission should create more self-productivity for such role!
J
Johnny Cho
Whenever someone has permissions to create/edit ANYTHING, please also allow them to DELETE it as well. Sometimes tasks/subtasks get created by accident and you should be able to delete the thing you just created, without having to bug someone else to delete it for you.
Load More
→