Granting Permissions
Current permissions on the adminui side are too simplistic, they give too much control. I have helpdesk staff that need the ability to launch Scripts, manage Computer Inventory, and add/edit things in Assets. We are a smaller IT shop, which is the reason our staff has more than tickets to do.
I'll use the Assets tab as an example. I need the ability to give some users the ability to Create and Edit in some Assets, but not have the ability to Delete. Some other Assets I don't want them to have anything other than Read. Some other users I need them to have the ability to Create only, while not having the ability to Edit or Delete.
So, essentially, in Assets (and across the entire KACE appliance actually) I need to be able to control permissions to sub-tables of Assets, like Computer, Cost Center, Software, Vendor, and not to only the main Assets table as it is now. So, like in your attachment below there would be additional permissions under Assets for setting sub-table permissions of whether Hidden; Read; Read, Create; Read, Create, Edit; Read, Create, Edit, Delete.
The current permissions are too simple, they either give too much access or too little. Current permissions are like this:
Hidden
Read
Read, Create, Edit, Delete
I need permissions like this:
Hidden
Read
Read, Create
Read, Create, Edit
Read, Create, Edit, Delete
This same permission access I would LOVE to have across the entire KACE appliance, not just for Assets. The following tables I have had problems with permissions (this includes ALL sub-tabs, i.e. like "Service Desk > Tickets" and "Service Desk > Knowledge Base"): Inventory, Asset, Distribution, Scripting, Service Desk. I have no ability to restrict Help Desk technicians from seeing either too much information or irrelevant information (depending on the sub-table info contents), having no ability to prevent them from deleting something or modifying something, yet I need them to be able to execute a script, which of course gives them the permission to modify and delete, which is unacceptable, therefore I can't have them execute scripts because of permissions giving more than necessary access.
Jesse
shared this idea
-
KACEfun
commented
Has this EVER been added? I need the same granular permissions and labels do not seem to work for assets.
-
aCuriousKace
commented
The recent 8.0 permissions changes help, but there is more work to be done regarding permissions. For instance, we should be able to grant access to specific patch schedules without also granting access to the catalog, subscriptions, patch download settings, etc.
-
Jason Valenti
commented
Currently KACE 1000 has very broad role based permissions. We would like to see a more granular option for added permissions. For example, we would like to have specific KACE users be able to edit certain Scripts or Labels, but we do not want these users to have complete write to the scripting tab. The current permission system makes it hard to control what people can and cannot do. Currently we have a master admin and a few other admins if required. Allot of the initial work is done by and admin and we would like maintenance work passed on to the client support team who can add users to an installation for example. Permissions that are more granular is what the ultimate goal is here. We Really could make use of this feature. Votes are greatly appreciated!
-
Jesse
commented
I'm still needing this feature, going on 4 years 8 months and still not implemented.
-
Jesse
commented
I find it very disappointing that this feature I requested isn't available still, after more than 3 years!
-
Dave Dewire
commented
I agree, the current permissions are to simple. I just had someone rename an asset type and it doesn't even log who did it let alone prevent them from doing it.
-
Gary
commented
This is one of the biggest issues I have with KACE is the lack of ability to set permissions. As you say it it very much Hidden, Read or RW nothing in between.
There is definitley a case for more refined permissions. We have a number of areas where it would be sensible to allow users to create stuff but we have to restrict as this also give them delete permission.