[
https://issues.jboss.org/browse/RTGOV-649?page=com.atlassian.jira.plugin....
]
Gary Brown commented on RTGOV-649:
----------------------------------
As mentioned on the call, this automated approach will only be possible if the resubmit
client gets notified of the error - i.e. as a synchronous response to the resubmitted
service call.
So for example, the situation may be resubmitted, and the service call does not return an
exception - indicating that the service call worked. This will be used to set the status
to RESOLVED. However later on, when the activity information is reported to the server, an
EPN processes the information and determines a problem occurred, and creates a new
Situation. This Situation will be a child of the resubmitting situation, but the status
would have already been changed to RESOLVED.
If this is going to be a problem, then the only option would be for the EPN creating the
situation to also have additional logic to 're-open' the parent situation. Is this
required?
Status handling for Situations
------------------------------
Key: RTGOV-649
URL:
https://issues.jboss.org/browse/RTGOV-649
Project: RTGov (Run Time Governance)
Issue Type: Feature Request
Reporter: Werner Müller
Assignee: Gary Brown
This relates to
https://issues.jboss.org/browse/RTGOV-645. To support the Resubmit
feature, the handling of the Situation's Status field shall be changed:
- Only 3 Status values shall be available: UNRESOLVED, IN PROGRESS, RESOLVED:
Either remove other values, or provide means to configure the values.
- The default entry for the Status filter on the Situations page shall be (the new value)
OPEN:
This includes all Status values other than RESOLVED.
- A Situation's Status should be changed only programmatically (see below):
Either remove the status change buttons on the "Details" tab or provide means
to hide them by configuration.
- The "Assign" button shall be available all the time. It potentially
overwrites an existing value for 'assignedTo'.
(This is to be consistent with the resubmit behaviour as defined below.)
- The initial state of a (root) Situation is UNRESOLVED.
When a Situation is resubmitted:
(1) 'assignedTo' is set to the current user (overriding the current value)
(2a) If no failure is encountered (no child situation is created),
the Status is changed to RESOLVED.
(2b) If a failure is encountered (and a child situation is created),
the Status is changed to IN_PROGRESS.
- A Situation in Status RESOLVED must not be resubmitted anymore:
(1) The Resubmit button on the "Message" tab is disabled.
(2) The Situation is excluded from a bulk resubmit.
As already stated in the requirements for RTGOV-645, assignedTo and Status shall have
the same value for all Situations in a "resubmit tree".
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)