Hello Marc,

Thank you for the request, but what will be the key benefit of that implementation? I mean when you are Super Admin - Zabbix wouldn't perform the additional permission check, but in your scenario - this will be an additional check which will provide an additional load on the DB/Web server.

Regards,
Aleksejs!

What costs more from a performance perspective - doing a permission check on every page for an additional user or loading ALL data for every host group on every page you open when as a Zabbix Super Admin you are only interested in health of your Zabbix server and it's surrounding environment?

aleksejs.petrovs,

you're right! There will be additional things to do for Zabbix Super Admins but not notable more than it is already done for regular users. Iiirc the current implementation of permission checking just drops these checks, if the user in question has the user role Zabbix Super Admin. This should not be that difficult to make it switchable.

The user role Zabbix Super Admin is imho not related to do any monitoring tasks. It's major purpose is for controlling and managing a Zabbix platform. However, it's not unlikely that users who are managing a Zabbix platform do want to do some individual monitoring tasks as well. One scenario could for instances be an organization with dedicated departments for database-, storage-, operating system-, application-admins... you name it. Now presume the Zabbix platform there is managed by Linux admins. In the current implementation they are doomed to see everything - what may be a lot!
Right now, the only mitigation is to either fiddle around with some filters or to have two separate Zabbix users sign-in with.... but doing so could rather be considered as a work-around than a solution.

ingus.vilnis,

As mentioned in my previous comment, I was not thinking of a frontend located check.

What I had in mind instead was to extend concerned API methods with a new parameters of type flag, let's call it "virtual_admin". If this parameter is set to True and the user is of type Zabbix Super Admin , then the regular permission check logic is not dropped resp. omitted but applied accordingly. Whether or not this parameter gets passed is controlled by a corresponding link resp. button in the frontend and it's current state could be stored in, resp. derived from a cookie or the user's profile table.

Hi Marc,

My reply was more to the comment posted previously and supporting your request. In normal daily activities one does not need to load all data, and this indeed is an issue in larger organisations. I know, filtering etc, but that is not it. So I say this is a valid issue and hopefully will be done some time in the future. 

My bad. Sorry, for having misunderstood your reply and Thank you for supporting my request

Or maybe that flag could be numeric as a down level to User type of account:  from 0=Zabbix Super Admin (^{no change})  to ... 2=Zabbix User  or  to show like  3=Guest

Yes - this is rather for ZBXNEXT-2018

[email protected],

Host access wise (incl. Items, Triggers, Graphs, etc) there is no difference between the User type Zabbix user or Zabbix Admin.
Here it is really only about enabling a user to be a Zabbix Admin with unlimited permission to the platform while also allowing him or her to limit the access to hosts of interest only. Supporting to switch to virtual_user would just remove (permission to) some tabs of the main menu.

But possibly I've just misunderstood the idea behind "2=user". I've just recently proven that this is not unlikely to happen to me

Edit:

Could it be that it's rather ZBXNEXT-2018 what you had in mind?

But  What if I will test permissions of any user. We missing permisions owerview for hosts on user like in old Zabbix 2.2 . (Also this is not Trivial change.)

Simulating permisions of any existing user for Zabbix Super Admin can be useful too (Just for noedit navigation).

Well, testing permissions of any user, resp. simulating permissions is actually exactly what ZBXNEXT-2018 is supposed to offer.