[ZBXNEXT-4446] Change the severity of a problem (Z4) Created: 2018 Mar 26  Updated: 2024 Apr 10  Resolved: 2018 Jun 28

Status: Closed
Project: ZABBIX FEATURE REQUESTS
Component/s: Server (S)
Affects Version/s: None
Fix Version/s: 4.0.0alpha8, 4.0 (plan)

Type: Change Request Priority: Critical
Reporter: Rostislav Palivoda Assignee: Andris Zeila
Resolution: Fixed Votes: 1
Labels: acknowledges, problem, severity
Σ Remaining Estimate: Not Specified Remaining Estimate: Not Specified
Σ Time Spent: Not Specified Time Spent: Not Specified
Σ Original Estimate: Not Specified Original Estimate: Not Specified

Attachments: PDF File ZBXNEXT-4446_+Change+the+severity+of+a+problem.pdf     PNG File emails.png    
Issue Links:
Causes
causes ZBXNEXT-4792 Make {ITEM.LASTVALUE1} useful again i... Closed
Duplicate
is duplicated by ZBX-12165 Close problem option works only for l... Closed
is duplicated by ZBX-11533 Incorrect information about recipient... Closed
Sub-task
depends on ZBXNEXT-1629 Allow leaving comments without having... Closed
depends on ZBXNEXT-4622 Improve UI/UI of problems with change... Closed
part of ZBX-12580 'Problem hosts' widget should load da... Closed
part of ZBX-14425 Data overview should load data from p... Closed
part of ZBX-14426 Host issues and Host group issues sho... Closed
Sub-Tasks:
Key
Summary
Type
Status
Assignee
ZBXNEXT-4447 Frontend - Change the severity of a p... Change Request (Sub-task) Closed Valdis Murzins  
Team: Team A
Sprint: Sprint 30, Sprint 31, Sprint 32, Sprint 33, Sprint 34, Sprint 35, Sprint 36, Sprint 37
Story Points: 5

 Description   

The problem acknowledgement form must be extended to support:

  • Ability to change existing problem severity to a new one
  • No special user permissions will be required for this operation
  • History of acknowledgements must be extended to display this operation so that old severity and new severity are clearly visible
  • API must support change of severity and getting last problem severity.

New set of macros for retrieval of problem severity must be supported.

Change of severity will impact visualization only. Other functions such as notifications, trigger, macros, IT Services, etc will not be affected.

The problem acknowledge form must be renamed to "Update problem" (feel free to propose a better naming) and extended to support:

  • optional actions none, acknowledge, close problem and change severity
  • optional message
  • acknowledge operation will be allowed only for unacknowledged problems
  • history of problem updates must clearly display what operation was performed
    All occurrences of displaying of the Ack flag (list of problems, dashboard widgets, etc) will be modified to display just Yes (no number) or No in the "Ack" column.

All occurrences of displaying list of performed actions for a problem (column "Actions" in the list of problems, dashboard widgets, etc) will be extended so that:

  • on mouseover, merged timeline of both actions and list of trigger updates must be displayed
  • the column must display relevant icons for different operations:
  • messages + number of messages (if any), on mouseover we must see timeline of these messages with corresponding actions
  • change of severity (if any), on mouseover we must see who and when changed severity, also display old and new severity
  • close problem (if closed manually), on mouseover we must see who and when closed it
  • actions + number of actions (if there are at least one action), red icon ? there are failed actions; on mouseover we must see timeline of all actions: automatic + manual
    A database patch must be created to ensure that we have only on? acknowledge operation (first one) in the list of acknowledges for each problem.

Things to consider during implementation

  • Similarly to events, table "problem" should probably be extended to contain "ack" flag in order to speed up displaying of problems. The flag should be updated by front-end. A database patch is needed in order to populate this field.
  • Exact visual design of the Action column must be agreed during design phase.
  • We should not split existing table "acknowledges", let's keep things simple for now.

 

Specification: [^DEV-31720708-070518-1817-110.pdf]



 Comments   
Comment by Rostislav Palivoda [ 2018 Jul 02 ]

Technical specification - ZBXNEXT-4446_+Change+the+severity+of+a+problem.pdf

Generated at Tue Apr 23 14:14:39 EEST 2024 using Jira 9.12.4#9120004-sha1:625303b708afdb767e17cb2838290c41888e9ff0.