Details

    • 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]

        Attachments

          Issue Links

            Activity

              People

              • Assignee:
                wiper Andris Zeila
                Reporter:
                palivoda Rostislav Palivoda
              • Votes:
                1 Vote for this issue
                Watchers:
                12 Start watching this issue

                Dates

                • Created:
                  Updated:
                  Resolved: