possible solution :
allowing to set permissions based on applications.
this would require making applications non-exclusive (so that multiple templates with same app can be linked to single template/host).
such an approach would allow to set permissions on item level with great flexibility.

not sure if applications are the way to go for this.
as another example: consider a wireless endpoint. it has various properties (such as signal-to-noise, management vlan, "real" vlan, frequency etc).
we want admins to see all of them, but we want to hide stuff such as frequency and vlans from users.

making different "applications" to categorize the fields may be a bit too far fetch.
i suggest to just have a better permission editor where you can select/hide fields for certain users/usergroups

maybe, but it would offer much easier configuration afterwards. want to allow some user to see all in/out counters on all your switches, but nothing else ? allow access to one or two applications.
want to do that w/o apps ? frantic clicking until you have configured that for 300 hosts.

sorry i wasn't specific enough. the way i see it the single fields that you can select would be exceptions on a "base" rule. and you could toggle the base rule to be "allow everything" or "allow nothing".
and of course, you'd be able to configure this for hostgroups, not only per-host

partially connected to ZBXNEXT-142

Hi,

It's possibility that the implementation of the rights for user, who can for example disable him own action.

I have a user who wished something like that, and now I give him account which zabbix administrator rights, and he see other actions.

not quite sure what the latest comment implies, but since 1.8.2 zabbix admins can only see actions where all the recipients share a group with them

Hi,
IT is very usefull feature, but it is still unassigned. Could you anounce the approximate date of that feature release.

richlv, you mention setting permissions based on applications - is this something that has been implemented already (v1.8.3)? If not, are there plans to in the 1.8 trunk?

application based permissions are not implemented yet;
1.8 branch is not trunk;
it definitely won't appear in 1.8 branch;
i'm not aware of any specific plans to implement this.

my idea:
grant user to templates and they have automatically access to all hosts where the template is attached, but only to the items and graphs in the template

We have many customers use our system and would really like to limit what they can see, such as dashboard, latest data, graphs, screens, but not other things - be nice to control this beyond just read/write.

Totally agree. We are considering migrating to Zabbix in our organization, but rough permission granularity might be a show stopper for us .

A colleague of mine, proposed this dirty workaround:
create multiple zabbix hostnames for the same IP/DNS name.
eg. "myhost_infra", "myhost_app" and add it to the corresponding hostgroups. And give _infra ones to sys admins, _app ones to app/dev team.

While it would work, it's not very nice and brings additional complexity/confusion.
Also, it doesn't resolve Templates permission granularity for us. Having a choice between "All templates" or "None" for a user is not enough.

P.S. Maybe anyone knows how to workaround Templates permissions?

templates may belong to several hostgroups as well, you are not required to put them in the "Templates" group

Thanks Rich, (That was fast btw! )
That does make it a little easier for us...

Would the following fall within the scope of this feature request? :

We'd like to be able to give user groups (they may need to be Zabbix admins) permission to modify Maintenance periods without giving them permission to modify all other aspects of configuration for those hosts (e.g. the main configuration of those hosts, such as name, group membership, agent IP address / name, linked templates, etc).

Presumably such a feature would make configurable on a granular level which aspects of configuration (e.g. maintenance periods, linked templates etc) are being granted to the user group for the hosts (or host groups) specified.

Another use case I have that may fall under finer permissions is the "Host Name" vs "Display Host Name." I'm intending to automate the creation of hosts through the JSON API with a specific "Host Name" internal identifier, once it is created I don't want that value to change so later on I can reliably query information about that specific host using that "Host Name". Through the frontend I would like the "Host Name" field to be disabled when modifying a host but still allow the user to change the "Display Host Name" if they wish to have the host name visually represented differently.

Permission granularity could be implemented almost anywhere, but the reporter was mostly talking about permissions on specific items, graphs...

IMO if you want to make this right, the first thing that needs to be added is the ability to set read permissions for every item to a group and/or a user. By default the permissions should be set to allow all (or host based). This would be extremely useful if you would like to hide some business sensitive information from some users. Also these permissions should work on actions and notifications, so that those users don't get any notifications for items they don't have read access.

Hi

I´m used to the "HP Software Operations Manager" way to do this. Yes, I agree that it would be nice to have better permission granularity.

Create a matrix -> Application x Host group
For each user (or user group) make it possible to select, in the matrix, what the user/user group should have access to see. E.g.

-----------------------OS----Database---ZabbixInternal
ZabbixServers-----------X--------X
Linux servers------------X
Important servers-------X--------X

This way I can say that e.g user group "AAA" should not have access to see zabbix Internal (e.g. zabbix agent ping) trigger-events.

IMO Permission granularity should also include which menu-tabs will be displayed, many managers/customers ask for a simple perspective. Inventory and reports, and actually anything but a single or a couple of screens is confusing them.
Customers that were interested to install a monitoring solution often said "It's way too complicated to use, can't you just build me a page with the good old MRTG of the data I need?"
IMO Zabbix is amazingly powerful and should stay like this, but it should also provide granularity on the interface for non-techies. The overloaded "user" interface is often a sale stopper at the management level.
Maybe the solution is a "one screen user" including the Permission granularity as other asked, and without all the menus, options etc..

In my opinion this is a really useful feature. I really need it. To date, I have to use the Cacti to allow viewing only part of the device.

+1 for the feature of allowing users access to maintenance settings, but not to hosts configuration. Maybe a new user type could be used?

I also would appreciate the feature for users to add maintenance for host/groups without host configuration!

I would like to have the feature to be able to be able to give select Zabbix Admins the ability to create host groups.

Is there a chance that you have this in your future plans? These closer ones

Today we have to give full access to users that we would like to allow only create maintenances.
It would be nice to have better permission granularity so we could give access only to what is needed.

Gustavo, I have a partial solution to your particular problem as part of http://zabbix.org/wiki/Docs/simplify_ad_hoc_maintenance#POC_implementation

This change exploits the fact, that "write" can be set for non-admin users, but it has no meaning, which is confusing in itself. My change introduces the semantics of "Write" meaning, maintenance can be set – at least on the API level. This is tricky to expose in the UI though for various reasons. I simply added a host popup-menu entry and an entry on the Monitoring menu, which is not consistent, but works very well.

Volker,

Thank you very much for your suggestion but I'm affraid the patch is not compatible with the version I'm using.
I think this feature is not complex to be implemented and would like the developers add it on the next versions.

Tag filtering implemented in Zabbix 3.4 covers some of the use cases related to more granular user permissions. Tag filtering will bring even more practical value as soon as we implement host- and (possibly) item-level tags.

alexei, what finally would mean following the intention of ZBXNEXT-2976

problem is at the moment that there is no lookup table for tags when you specify them. making this sensitive to errors already at the moment.

Imagine what it will be when we add more complexity like permissions.

More then 10 years ... it seems like it's never happening

it will if you are happy to sponsor this feature 

Actually it is not about sponsorship, it is about finding a good solution that will satisfy most of user cases we have here. I have to say that I am not happy about item/trigger-level granularity, we've been there in Zabbix 1.0. It will be a nightmare to manage permissions in this case.

I think that what is really missing is ability to restrict access of end-users to certain parts of Zabbix UI (like I want to see dashboards only, nothing else; or I want to hide Monitoring->Services) and certain functions like problem acknowledgements, ability to create/edit dashboards, ability to create maintenance periods, etc.

We could possibly implement this functionality as support of user roles (like "Customers", "Marketing", "Network engineers", etc). A user role could be assigned to an user (one role for each user) and it will define user type (user, admin or super admin), what parts of UI are accessible and what specific functionality is available to the user role (maintenances, problem acknowledgement, ability to create/edit dashboards, ability to create/edit maps, etc). It will be kind of additional filter for UI functionality.

What do you think?

imho this is the way to go 

user defined roles where you can define what is possible and what is not possible like for example create the maintenance. something i fix now with frontend scripts.

like you mentioned adding permissions on triggers is way to complex and will only lead to the windows way with acl hell

problem with admin today is imho that it can not be restricted to for example not create discovery rules while normal users cant see the templates etc ...

That is exactly what I've been needed six years ago

I think user roles would be very nice. But I think it's not only a matter of restricting which role can access which part of the UI, it's also a matter of defining which role has which rights to the parts of the UI.
Mostly you want to restrict the configuration of Zabbix to a limited group of people, but you don't necesseraly want to hide the configuration for all users. Sometimes it's nice for certain users to be able to see how everything is configured without being able to alter it themselves.

Another annoyance today is that read-write permissions are required to be able to manually close a problem, but at the same time read-write also allows the user to change the problem severity. Which is not always desirable.
Sometimes you just want users to be able to manuallly close certain problems because it's not possible to recover the problem automatically. But you don't want these users to fiddle with the severity levels.

And of course people who create maintenances are most of the time operators and not the same people who configure and maintain Zabbix.
So there should be some kind of operator role that can't configure hosts, items, triggers, graphs, etc. but which can create maintenances.

joachim.vertommen, in case if we implement user roles the way I described, we will not require read-write permissions for certain operations like changing problem severity, creation of maintenance periods, etc. Read-only will be sufficient.

I understand what you mean about having access to configuration data for non-admins. Introduction of Monitoring->Hosts, ability to manage dashboards for all users are just a few steps we have made in this direction. Ideally I would like to see most of Configuration merged with Monitoring in the future.

If the permissions for each operation can be chosen individually then what you describe indeed seems like a very good solution.

"It will be a nightmare to manage permissions in this case."

Alexei, in our zabbix instance we have to add the same hosts/items twice and create additional host groups to allow customers view only their specific items. So my vote goes to "nightmare permissions"

Rostislav I understand your challenge. I guess we have to find a good balance between usability and flexibility.

We are developing support of user roles under ZBXNEXT-6148, which will hopefully be ready in Zabbix 5.2. I hope that it will cover most of use cases mentioned here except perhaps ability to define permissions for different set of items of the same host.

Hello Alexei,

Can you add a use case to restrict manually closing of problems by certain users?
Thanks.

joachim.vertommen It will be implemented under ZBXNEXT-6148. Currently there is one role to allow "update problems" type of operation, which includes also acknowledgements. In the future it could be made more granular.

Not closed by https://www.zabbix.com/documentation/current/manual/web_interface/frontend_sections/administration/user_roles ?

@mma, I would say that we can close it, any objections?  Likely some users here are waiting for item level granularity, which I believe will never be implemented.

For me, since 5.2, Zabbix has a good granularity, it's a great work.

All right, I think it is fine to close this ticket then.