Bug 817185 - Child compatible group name displayed as ... in navigation tree after a group member's name is changed
Child compatible group name displayed as ... in navigation tree after a group...
Status: CLOSED CURRENTRELEASE
Product: RHQ Project
Classification: Other
Component: Core UI (Show other bugs)
4.3
All All
high Severity medium (vote)
: ---
: RHQ 4.5.0
Assigned To: Jay Shaughnessy
Mike Foley
:
Depends On:
Blocks: 817165
  Show dependency treegraph
 
Reported: 2012-04-27 19:22 EDT by Larry O'Leary
Modified: 2013-09-01 06:03 EDT (History)
2 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: 817165
Environment:
Last Closed: 2013-09-01 06:03:34 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)

  None (edit)
Description Larry O'Leary 2012-04-27 19:22:44 EDT
+++ This bug was initially created as a clone of JBoss ON Bug #817165 +++

Description of problem:
When a compatible resource of the same type and name is in a child or decedent compatible group (a logical grouping of the same resource as it exists across multiple parents) the group name is equal to the name of its children. For example:

/JBoss AS 5 Servers
 / Applications
   / Embedded Web Application (WAR)s
     / invoke.war
     / jbossws-management.war
     / web-console.war
       / Embedded Web Application Contexts

In this case, web-console.war is a compatible group containing all the web-console.war application resources deployed in all the parents of the group.

If the name of one of these resources in the group is changed, the result is the group name displayed in the navigation tree is "..."

/JBoss AS 5 Servers
 / Applications
   / Embedded Web Application (WAR)s
     / ...
       / Embedded Web Application Contexts
     / invoke.war
     / jbossws-management.war


In this case, the resource name of one of the web-console.war resources was changed to something else.

The problem with this is that now the navigation tree gives no indication what this is. If I repeat the rename for other WARs, I end up in a situation like this:


/JBoss AS 5 Servers
 / Applications
   / Embedded Web Application (WAR)s
     / ...
       / Embedded Web Application Contexts
     / ...
       / Embedded Web Application Contexts
     / ...
       / Embedded Web Application Contexts



Version-Release number of selected component (if applicable):
JON 3.0.0

How reproducible:
Always

Steps to Reproduce:
1.  Install two EAP 5 servers and start them both using a profile based on **default**

    -   The goal is to have two EAP servers in inventory of the same type and with the content
    
    1.  Copy <JBOSS_HOME>/server/default to <JBOSS_HOME>/server/server1 and <JBOSS_HOME>/server/server2
    2.  Start server1 as normal
    3.  Start server2 using -Djboss.service.binding.set=ports-01

2.  Install JON system and start it
3.  Import both EAP servers into inventory
4.  Create a recursive group containing all JBoss AS 5 servers from JON inventory

    1.  From **Inventory** select **Groups / All Groups**
    2.  Click **New** button
    3.  Set **Name** to `JBoss AS 5 Servers - Recursive`
    4.  Check **Recursive** check-box
    5.  Click **Next**
    6.  From **Category** drop-down, select **Server**
    7.  From **Type** drop-down, select **JBossAS5 Plugin -> JBossAS Server**
    8.  Move two or more EAP 5 resources from the left to the right **Assigned Resource** list
    9.  Click **Finish**

5.  Verify the new group **JBoss AS 5 Servers - Recursive** contains the child auto-group **Applications / Embedded Web Application (WAR)s / web-console.war**

    - See attached screen shot *screenshot-01-auto-group-view-web-console.war.png*

6.  From the **Inventory** page, select **Resources / Servers**
7.  Locate and select the EAP server resource which is using the *server2* configuration from the platform that was added to the *JBoss AS 5 Servers - Recursive* group
8.  From the left navigation tree, expand and select **<platform> -> JBossAS Servers (JBossAS5 plugin) -> EAP <host-name>:1199 server2 -> Applications -> Embedded Web Application (WAR)s -> web-console.war
9.  Expand the **web-console.war Embedded Web Application (WAR)** detail panel by clicking the icon to the left of the title

    -   See attached screen shot *screenshot-02-web-console.war-expand-detail-panel.png*

10. Hover over the **Name** field value until the edit icon appears (the pencil) and then click the edit icon

    -   See attached screen shot *screenshot-03-web-console.war-detail-panel-edit-name.png*

11. Change the name to something else

    -   For example, **web-console.war** to **RENAMED - web-console.war**

12. Click the check-mark icon to save the change

    -   You should see a success message *Name of Resource with id 10186 was changed from [web-console.war] to [RENAMED - web-console.war].*
    -   See attached screen shot *screenshot-04-web-console.war-detail-panel-renamed.png*

    **Observation** The left navigation panel still reflects the original name

13. From the **Inventory** page, select **Groups / All Groups**
14. Select the **JBoss AS 5 Servers - Recursive** group from the group list
15. From the left navigation tree, expand and select **JBoss AS 5 Servers - Recursive / Applications / Embedded Web Application (WAR)s / ...**

    -   See attached screen shot *screenshot-05-auto-group-view-noname.png*

    **Observation** Notice that the name displayed in the navigation tree is **...** instead of **web-console.war** as it was before
    **Observation** Notice that the name displayed at the top of the resource detail panel is **Group of Embedded Web Application (WAR) Compatible** instead of **web-console.war Compatible** 

  
Actual results:
Child compatible group name is displayed as "..." in navigation tree

Expected results:
Navigation tree should display actual group name as it appears in the resource group detail panel.

Additional info:

The reason this is happening is because the resource name is used as the auto-group name and the contents of the auto-group is determined by the resource key. In this case, the resource key for both web-console.war resources is **{default}console-mgr.sar/web-console.war**. So, even though their names could be different or changed, as long as their keys are the same (and their resource types are the same of course), they will be put into the same auto-group. The groups name is then determined based on the name of the resources that make it up. In the case that the resource names are different, the generic name **Group of Embedded Web Application (WAR)** is used. However, this name is not rendered in the navigation tree. 

At bare minimum, the expectation is that the actual auto-group's name should appear in the navigation tree. This would allow the auto-groups name to be changed and the change be reflected in the navigation tree. Additionally, the *...* is not an appropriate or meaningful name to appear in the navigation tree.

The expected behavior is definitely up for interpretation. For example, it could be easy to see how a user might want:

-   the two resources in the auto-group to be split apart into their own auto-groups

    - auto-group contents is based on name and key so that one could have a auto-group of **web-console.war - production** and **web-console.war - development*

- or to have the group's name remain what it was originally
- or to have the group'w name remain what it was originally with some kind of icon or symbol to denote that the actual resources contained within have varying names

--- Additional comment from loleary@redhat.com on 2012-04-27 17:45:22 EDT ---

Created attachment 580874 [details]
screenshot-01-auto-group-view-web-console.war.png

Created attachment 580875 [details]
screenshot-02-web-console.war-expand-detail-panel.png

Created attachment 580876 [details]
screenshot-03-web-console.war-detail-panel-edit-name.png

Created attachment 580877 [details]
screenshot-04-web-console.war-detail-panel-renamed.png

Created attachment 580878 [details]
screenshot-05-auto-group-view-noname.png

--- Additional comment from loleary@redhat.com on 2012-04-27 17:47:39 EDT ---

This issue is similar to Bug 734592.
Comment 1 Jay Shaughnessy 2012-05-02 15:13:20 EDT
I understand the issue and will look into what can be done. As Larry surmised,
the backing group for the AutoCluster is derived by the ClusterKey, which
correctly uses resource keys, resource types, and ancestry to determine
membership.

The assumption is that the members will have the same name, which is
a fair assumption as likely the group is comprised of members that
are targeted as being managed as an identical group.  But I agree that
"..." is not appropriate.

There are a few options but one option that will not be in play is
separate tree nodes based on the resource names.  That conflicts with
the underlying idea of AutoClusters and recursive compatible groups.  The
solution will likely be a better node name and, possibly a hover with
the varying member names, if possible.
Comment 2 Larry O'Leary 2012-05-02 18:57:41 EDT
Understood. I like the hover idea. This could be useful if the group contains mixed names (web-console.war (7), RENAMED - web-console.war (1))

Of course, just to note, it appears that we already have the concept of "Group Name" for these nodes. The navigation tree just isn't using it. I can even rename the group. By default, the group name is set to the child resource names. However, in the event that they vary, it appears that a generic name is used. As shown in attachment 580878 [details], this is "Group of Embedded Web Application (WAR)" in this case. This name can be set to something else in the same manner a resource can be renamed.
Comment 3 Jay Shaughnessy 2012-05-09 14:51:10 EDT
Unfortunately the tree node and the group are not all that easy to
coordinate.  The node comes before the autocluster backing group.  The groups
are, for good reason, created (and later updated) lazily, not until
the user clicks on the node.  It's not feasible to create a hover
with the group member names.  So, we'll suffice with just changing
the "..." to "Group of <ResourceTypeName>".

Note that the node name will be localized.

When the backing group is created for an autocluster of this type (i.e. with
disparate member naming) it assigns the default name of "Group of
<ResourceTypeName>".  So, we're matching the node name with the group name.
Unfortunately, the group name generated on the server is *not* localized
(nor could it be, as it is in fact the persisted group name).  So, I added some
brute force code in the GUI to localize the displayed group name in this
situation. 

(note, I suppose we could have just set
the name to something like [<ResourceTypeName>] in all cases and not have
had to really do this name mucking, but "Group of" seems nicer.)

The reproduction steps above specify that the autocluster group name
be edited.  This is actually a bug in itself.  Like autogroups, generated
backing groups are created by RHQ for convenience. They are not user
created and should not be editable.  I have removed the ability to edit
the backing group name and recursivity.

It is still quite possible to create the desired situation. Simply create a recursive compatible group of disparate objects. For example, a group of
AS5 WAR files.  The Web Application Contexts will have disparate members
(because they have the same clusterKey but different resource names). Note
that this whole scenario will probably be rare as recursive compat groups are
typically used for a group of like, not disparate, resources. Such as a
group of logically equivalent App Servers (i.e. a "cluster").
Comment 4 Jay Shaughnessy 2012-05-09 15:31:52 EDT
master commit 87d76b8a0b4f8138d192b2f2b809a18b98e8239a

- Now displays localized version of "Group of [<ResourceTypeName>] for:
  - AutoCluster Tree Node
  - AutoCluster Group Detail Title bar
  - AutoCluster Group Detail General properties
- No longer allow editing of AutoCluster Group Detail General properties


Test Notes:
please read comment #3 for more info.
Comment 5 Heiko W. Rupp 2013-09-01 06:03:34 EDT
Bulk closing of items that are on_qa and in old RHQ releases, which are out for a long time and where the issue has not been re-opened since.

Note You need to log in before you can comment on or make changes to this bug.