[
https://issues.jboss.org/browse/RTGOV-645?page=com.atlassian.jira.plugin....
]
Gary Brown commented on RTGOV-645:
----------------------------------
*Requirements currently not being considered:*
* Represent situations in a tree representing the resubmission failures
{quote}
This is not being considered, as it assume resubmission failures are the primary focus of
the visual representation - whereas in most situations resubmission will not be used.
Therefore instead, the situation list will remain and a means of navigating the tree will
be provided on the situation details page.
{quote}
* The root node shows the number of resubmits so far (this is equal to the number of child
nodes).
{quote}
Not sure of the benefit of this? One resubmission may result in two or more situations
being created - counting nodes would then return an incorrect value. Resubmission count
would be more to do with the depth of the tree.
{quote}
*Requirements and Questions:*
* Only the newest situation in a tree is allowed to be resubmitted.
{quote}
Does this mean that situations that don't have any linked (child) situations can be
resubmitted any number of times, or should a situation only be able to be resubmitted
once, regardless of success or fail?
{quote}
* Filter criteria in the Situations tab apply only to root situations. If a child
situation would match the criteria, but the root situation does not, the whole tree is
hidden. This means that a tree is never shown partially. Either the tree is fully shown or
hidden. [This is a simplification, even though it may leave the user wanting more]
{quote}
As discussed above, the use of a tree is not appropriate for a majority of rtgov UI usage.
Another option may be to only show (and filter) the situations that are effectively leaf
nodes? If needing to access the intermediate or root nodes, then these could be done
through navigating from the leaf nodes?
{quote}
* Applying a bulk action on the Situations tab:
a) "Retry" and "Export" are applied only to the newest situation of
the selected trees.
{quote}
This would fit with the suggested approach above of only listing 'leaf'
situations.
{quote}
b) "Delete" is applied to all situations of the selected trees. Thus, it deletes
the whole tree.
* The "assignedTo" and "resolutionState" properties apply to the whole
tree. Whenever these properties are changed for a situation, the change is propagated to
all situations in the tree. When a child situation is created, these properties shall be
set according to the root situation's properties.
Resubmitted message should identify source situation to enable
further failures (situations) to be linked back
--------------------------------------------------------------------------------------------------------------
Key: RTGOV-645
URL:
https://issues.jboss.org/browse/RTGOV-645
Project: RTGov (Run Time Governance)
Issue Type: Feature Request
Reporter: Gary Brown
Assignee: Gary Brown
Fix For: 2.2.0
When a message, associated with a situation, is resubmitted, ensure that the situation id
is carried in a message header so that it can be included in resulting activity events.
If the resubmitted message results in further situations being created, then these new
situations should include the reference back to the originating situation id.
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)