very welcome resources. please implement as soon as possible

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 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.

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.

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.

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.

Some suggestions/thoughts after trying to work with permssions in clickup:

SPACE LEVEL PERMISSIONS NEED IMPROVEMENT:

-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:

MORE CONTROL OVER PERMISSIONS TO EDIT SPECIFIC FIELDS

PERMISSIONS FOR VIEWS:

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.

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!

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.