ZBX-4592 asks to allow mass enable/disable LLD items, which requires .... allowed check boxes in the items list .

Implementation of this feature would give green light to implement another one - ZBXNEXT-824

ability to get that form with editable fields is a bug, though

It turned out that editing or deleting LLD graphs possible by using API
Related forum thread (in Russian) http://www.zabbix.com/forum/showthread.php?p=112291ers

added:
testing -> LLD items (note a bug ZBX-5684) and LLD triggers also can be edited or deleted using API

This is a true at least for 2.0.3 and 2.0.4rc1-r31147

added:
This possibility reported as an issue in ZBX-6386

ZBXNEXT-1601 asks almost the same but for limited operations.

ZBXNEXT-2183 asks to allow to edit Hosts created by lld.

Triggers generated by templates should be editable to some extent. Like being able to classify their severity on each host is essential. For an example, on a switch the LLD templates are unable to determine a given port's severity and the administrator should classify the ports' triggers after the device is discovered.

I agree with Gergely Czuzcy.

The big problem is that I, as a user, cannot select in Zabbix front end LLD items and triggers to perform actions on them. E.g. to disable a dozen of items in one click. It makes working Zabbix extremely uncomfortable, and in some cases plain unbearable. The whole concept of "prototype thousands of items that you later cannot modify, until they're no longer discovered and removed at a set interval" is plain wrong.

Better than nothing, sure.. but... is basically unmanageable.

We're dealing often with hundreds of thousands of prototyped items and it is our luck we rarely needed to make massive modifications thus far.. but something tells me that is going to change soon as our monitoring gets more and more specific for each host that we monitor.

A simple effort like raising a threshold a bit for a single type of a check (e.g. a duration of a SQL query in each database) can demand a disproportionate amount of time. So, we might have 10 databases in a cluster, that's going to be about 10 items and triggers pairs. If we need to either modify a threshold or disable/enable these triggers we need to process them one by one, manually.

That is, this doesn't scale AT ALL.

It all works well if you have a lot of hosts that are very similar in configuration, as soon as you need to make specific changes for selected hosts based off mainly templated set of items and triggers.. life becomes hell

From a user's perspective it is a disaster. I have objects that I cannot manage.. all while in contrast to a pretty flexible UI that allows to go into a great detail of configuration. What's confusing me as a user even more is that I can pretty much do whatever I please with templated items. Which exacerbates the feeling that Zabbix is just stupid in this aspect.

So, I naturally assume that LLD objects will be as easy to manipulate but in reality managing them becomes next to impossible unless all I need to do is prototype objects in bulk and don't need to modify them in any way.

You see the problem is pretty insidious. If I disable a prototype of a trigger, the objects that were previously already created off of this prototype will never become disabled either. So, LLD at its current state is good only for bulk creation of items. Which is a great functionality, but all its positive value is destroyed by realization that one cannot do much with all those array of objects.

I've just talked to people in #zabbix and LzrdKing and pidzero at least share this feeling of despair.

It's incredible that Zabbix is at 2.4 these days and yet such a basic UI functionality hasn't been implemented it!

We sure appreciate all the hard work community puts into development of Zabbix, but let's face it this particular aspect has been neglected for too long.

I cannot stress enough how big of a problem it is from a user's perspective. It's an extremely limiting obstruction to managing objects in Zabbix. It turns the simplest of actions into drudgery and pushes people to commit suicides when they have to deal with hundreds of such prototyped items.

Save some lives, fix it! Please!

As for individual overwriting of thresholds / user macros in triggers, ZBXNEXT-1645 might help there too.

Dirty and easy fix - search in file include/views/configuration.item.list.php line

$checkBox->setEnabled(empty($item['discoveryRule']));

and comment/remove it.

Why are these actually disabled in the current implementation? actually obviously

For SNMP, please allow to see the resolved SNMP OIDs too! Right now you can only see the item name, which is not necessarily related to the OID.

I actually don't like the idea of editing discovered, volatile items, there are too many ways to lose the precious local modifications.

For adjusting tresholds, there's no need to edit items (at least in 2.2.6). Define a macro (f.ex. {$TRIG_FS_WARN}=80) in the template with the discovery rule, override the value in the host's configuration when required and use it in trigger names and expressions. Instant happiness.

Free space less than {$TRIG_FS_WARN}% on {#FSNAME}
{Template OS Linux:vfs.fs.size[{#FSNAME},pfree].avg(#3)}<{$TRIG_FS_WARN}

A way to set the trigger severity value with a macro could be a workable solution for the other half of this request and might even prove useful elsewhere.

Using Zabbix 2.4.5 and struggle with this issue as well.
I want to change the severity of a particular Windows Services that is being monitoring (and discovered by LLD) and I cannot do that.

I think phoemix and iliv nailed it. I can't fathom why this issue has not been resolved since 2011. For anybody doing serious monitoring, LLD is useless if you cannot tweak the created triggers. Even using host-level macros does not provide the granularity required for advanced scenarios. This was flagged as a "Major" priority in 2011, so really this should be addressed ASAP.

Thanks !

note that your needs might also be satisfied by usermacro/uservariable context - ZBXNEXT-2683

Unfortunately it does not. I guess we will have to keep disabling some LLD created triggers and manually create new ones with custom values until this get fixed. I might try to facilitate this by using the API to clone the LLD trigger.
Thanks.

addition to Andrey Melnikov fix

v2.5.0 and later
code has changed in file include/views/configuration.item.list.php

$checkBox = (new CCheckBox('group_itemid['.$item['itemid'].']', $item['itemid']))
	->setEnabled(empty($item['discoveryRule']));

It seems that comment/remove will break the page. So i change the ['discoveryRule'] to ['discoveryRule_removecheck'] and it works.

I recommended only to bulk enable/disable operation only with this fix, not to mass update the inner property of item. That maybe the reason why zabbix not implement it themselves.

Change

->setEnabled(empty($item['discoveryRule']));

to

->setEnabled(1);

Guys, don't spend your "coding" time here too much.
Some updates here from developers supposed to be soon (I think I may say that something supposed to be implemented in 3.2).

(1) Translation string changes:

Strings added:

• Cannot set "%1$s" for graph "%2$s".
• Cannot set "%1$s" for graph prototype "%2$s".
• Cannot update "%1$s" for graph "%2$s".
• Cannot update "%1$s" for graph prototype "%2$s".

Strings deleted:

• Cannot delete discovered item "%1$s".
• Cannot delete discovered graph "%1$s".
• Cannot delete discovered trigger "%1$s".
• Cannot update "templateid" for graph "%1$s".
• Cannot update "templateid" for graph prototype "%1$s".

gunarspujats CLOSED

RESOLVED in svn://svn.zabbix.com/branches/dev/ZBXNEXT-821

(2) Cannot create/update graph prototype

Cannot set "flags" for graph prototype "Traffic on interface {#IFNAME}".
Cannot update "flags" for graph prototype "Traffic on interface {#IFNAME}".

iivs RESOLVED in r60255

sasha CLOSED

(3) Take a look at my changes in r60243 and r60244

iivs Thanks!
CLOSED

(4) Coding style
1. items.php:
:448 - getting data for discovered item is superfluous
:762 - redundant assignment of itemid

2. triggers.php:
:198 - getting data for discovered trigger is superfluous

3. include/classes/api/service/CTrigger.php
:619 - missing dot after comment

4. include/views/configuration.triggers.edit.php
:295 - line length more than 120 characters

5. items.php:728 - not optimal realizations, getting same data for each item

gunarspujats 1., 2., 3. and 4. RESOLVED in r60378
gunarspujats 5. RESOLVED in r60379

sasha fixed update of items, triggers and trigger prototypes in r60492, r60493, r60494, r60495, r60499 and r60514.

RESOLVED

gunarspujats CLOSED

Tested

Available in pre-3.1.0 (trunk) r60538.

(5) Documentation

API documentation updated.

martins-v Updated documentation sections:

• What's new
• Upgrade notes
• Low-level discovery (screenshots; removed text that lld items cannot be deleted)
• Item configuration (screenshots)
• Trigger configuration (screenshots)
• Graph configuration (screenshots)

RESOLVED

sasha Old functionality was not changed! Information about it can be removed from Upgrade notes.

REOPENED

martins-v The specification, however, lists 'Upgrade notes', too. Should we ignore it?

sasha I removed 'Upgrade notes' from specification.

martins-v Thanks, RESOLVED

sasha CLOSED

(6) [F] Cannot full clone template with graph prototype, for example "Template OS Linux"

Cannot set "flags" for graph prototype "Network traffic on {#IFNAME}".
 [templates.php:313 → CApiWrapper->__call() → CFrontendApiWrapper->callMethod() → CApiWrapper->callMethod() → CFrontendApiWrapper->callClientMethod() → CLocalApiClient->callMethod() → CDiscoveryRule->copy() → CDiscoveryRule->copyDiscoveryRule() → CDiscoveryRule->copyGraphPrototypes() → CGraphGeneral->create() → CGraphPrototype->validateCreate() → CGraphGeneral->validateCreate() → CApiService->checkNoParameters() → CApiService::exception() in include/classes/api/CApiService.php:790]

iivs RESOLVED in r61051

gunarspujats CLOSED

Fixed in pre-3.1.0 (trunk) r61061