[ZBX-7545] Mass updating items may lead to (configuration) data loss Created: 2013 Dec 14 Updated: 2017 May 30 Resolved: 2014 Apr 15 |
|
Status: | Closed |
Project: | ZABBIX BUGS AND ISSUES |
Component/s: | Frontend (F) |
Affects Version/s: | 2.0.10 |
Fix Version/s: | 2.2.4rc1, 2.3.0 |
Type: | Incident report | Priority: | Major |
Reporter: | Marc | Assignee: | Unassigned |
Resolution: | Fixed | Votes: | 1 |
Labels: | massupdate, patch, usability | ||
Remaining Estimate: | Not Specified | ||
Time Spent: | Not Specified | ||
Original Estimate: | Not Specified |
Attachments: | ZBX-7545-2.0.10.patch ZBX-7545.png |
Description |
Mass update form may initially appear with all fields available before imploding them (in my case for ~10 sec). If it's technically not possibly to show the final form when ready it could probably a work-around to disable the update button until then. |
Comments |
Comment by Marc [ 2013 Dec 14 ] |
Happens only when user is member of a group with 'Debug mode' enabled. Now I'm pretty sure it's caused by over-stressing the browser. Gotcha! I don't think it's intended that way: --- SNIP Debug output --- 6. item->get [items.php:721] Parameters: Array ( [itemids] => [output] => Array ( [0] => itemid [1] => type ) ) --- SNAP Debug output --- Now I've to find out if it's my fault... Hmm... that's not good in case of a template item because $data['hosts'] will be NULL: --- SNIP items.php --- // hosts $data['hosts'] = API::Host()->get(array( 'itemids' => $data['itemids'], 'selectInterfaces' => API_OUTPUT_EXTEND )); $data['is_multiple_hosts'] = count($data['hosts']) > 1; if (!$data['is_multiple_hosts']) { $data['hosts'] = reset($data['hosts']); // set the initial chosen interface to one of the interfaces the items use $items = API::Item()->get(array( 'itemids' => zbx_objectValues($data['hosts']['items'], 'itemid'), 'output' => array('itemid', 'type') )); --- SNAP items.php --- |
Comment by Volker Fröhlich [ 2013 Dec 15 ] |
I confirm the behaviour for 2.0.8 and 2.2.1. It's only 3 seconds on my side though. |
Comment by Pavels Jelisejevs (Inactive) [ 2014 Mar 28 ] |
RESOLVED in svn://svn.zabbix.com/branches/dev/ZBX-7545. The problem was that when trying to mass update items from a template, the frontend performed an API request on items.php:834 that returned all of the items. When debug mode was enabled and there were a lot of items, that caused a considerable lag in the browser and the form was rendered with a delay. |
Comment by Pavels Jelisejevs (Inactive) [ 2014 Mar 28 ] |
Marc, thanks for pointing out the problem, otherwise I would be having trouble figuring out what caused it. |
Comment by Pavels Jelisejevs (Inactive) [ 2014 Mar 28 ] |
When fixing the issue I've discovered a related bug - <richlv> if it's about application updating in templates, that seems to be a regression from this issue - worked just fine before r44119 jelisejev Hm, I was sure I was able reproduced the issue before. When, anyway, now it will be handled in |
Comment by Ivo Kurzemnieks [ 2014 Mar 28 ] |
TESTED. |
Comment by Pavels Jelisejevs (Inactive) [ 2014 Apr 07 ] |
Fixed in 2.2.4rc1 r44119 and 2.3.0 r44120. CLOSED. |
Comment by richlv [ 2014 Apr 14 ] |
(1) regression - can't add/replace applications (mass update lost those two checkboxes) |