Bug 734592
| Summary: | in summary header for autogroups, Name, Description, and Recursive fields are editable and for some autogroups, the Name field contains the string "null (...)" | ||
|---|---|---|---|
| Product: | [Other] RHQ Project | Reporter: | Ian Springer <ian.springer> |
| Component: | Core UI | Assignee: | Jay Shaughnessy <jshaughn> |
| Status: | CLOSED CURRENTRELEASE | QA Contact: | Mike Foley <mfoley> |
| Severity: | medium | Docs Contact: | |
| Priority: | medium | ||
| Version: | 4.0.1 | CC: | ccrouch, hrupp, jshaughn |
| Target Milestone: | --- | ||
| Target Release: | JON 3.0.0, RHQ 4.3.0 | ||
| Hardware: | Unspecified | ||
| OS: | Unspecified | ||
| Whiteboard: | |||
| Fixed In Version: | 4,3 | Doc Type: | Bug Fix |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2012-02-07 19:19:28 UTC | Type: | --- |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Embargoed: | |||
| Bug Depends On: | |||
| Bug Blocks: | 734807 | ||
| Attachments: | |||
Created attachment 520686 [details]
screenshot
I also see the "null" in the Resource name for the Embedded WAR and JBossCache autogroups under the RHQ Server. I don't know what these all have in common... I don't think we should allow any editing of the fields. That is not really high priority but I'm setting to high due to the other part of this, the occasional null in the names. That's ugly and wrong. Although I did see it happen locally I can't get it to happen again, now. And I can't explain how it happens as it would seem a Resource.getName() method is returning null, which should never happen. It is not predictable, I could not get it to happen for the same autogroup twice. It would seem like the AutoGroupTreeNode.parentResource must have a null name when the tree is loaded. Again, I don't know how and I can't repro at the moment. Although ugly this does not prevent the use or usefuleness of the AG, so for now, I'm stopping the investigation to see if we can learn more going forward. Making fields read-only should be an easy fix IIRC this is one jay volunteered for, so pushing it into the RHQ4.2 bucket. If I misremembered Jay, please unassign and Heiko/Lukas triage it Jay says, he can not reproduce those, but that he has seen them in rare occurrences, but which does not limit the ability to use autogroups. Lowering the prio Created attachment 528842 [details]
Actually the editing of the name and recursiveness is still possible ; the name change is only on the right hand panel while the tree is still "right".
Created attachment 528843 [details]
Changes seem to go to a resource group 10001 which does not exist in the system
Looking into the r/w issue at least. 9f9f742 in master - making the details read-only for autogroups About the "null (type)" : This is set in org.rhq.enterprise.gui.coregui.client.inventory.groups.detail.GeneralProperties#onInit which gets its data from org.rhq.enterprise.gui.coregui.client.inventory.groups.detail.ResourceGroupTitleBar#update and the callback into the group manager org.rhq.enterprise.server.resource.group.ResourceGroupManagerBean#findResourceGroupCompositesByCriteria And indeed here the query does not return the name, authzType is NONE - changing to AUTO_CLUSTER does not change the behavior. Btw: displaying such an autgroup takes 4(!) calls into the backend, which takes 4 round trips to the database While my analysis was correct, the data the backend provides was pre-computed, so if the pre-compute put the null in, the backend call could only get null out. 45a797b in master -- code by Jay Shaughnessy QA: to test, you need to un-inventory stuff first, as otherwise you may have bogus entries in the DB persisted. documenting this BZ as having caused a regression with non-rhqadmin users...which is now https://bugzilla.redhat.com/show_bug.cgi?id=750897 This needs to be re-verified again as the previous fix was re-done to solve bug 751091. That fix was insufficient and has been fixed again. Note that 751091 does not need to be re-verified, only this bug. master commit f7523d5757af1d0955dc75358e0a9f4e54be43fe release_jon3.x commit 2932513b74ff180d201c1691745b8cffdbb4eb3f Test Notes: 1) If you have an RHQ server in inventory then un-import it. 2) Import RHQ Server resource 3) Navigate to your platform and start expanding nodes, continuing down into the RHQ Server resource. Click on all AutoGroup nodes and verify they get the correct name and are rendered correctly in the details main page. Make sure you go several levels deep in the tree. See bug 751091 for more, if you want to exercise a non-perm test case. changing status of VERIFIED BZs for JON 2.4.2 and JON 3.0 to CLOSED/CURRENTRELEASE |
Do we want to allow users to edit the name and description of autogroups? I know they're real groups under the covers now, so perhaps it's fine. In any case, I don't think we want to allow them to set the Recursive flag to true, since the group would no longer be a normal autogroup at that point. The second part of this issue only occurs for certain autogroups. Specifically I see it for autogroups of service-d-metrics Resources, which is a ResourceType defined in the perftest plugin. The Name field has the value "null ( service-d-metrics )". The "null" portion should instead be the Resource name of the autogroup's parent Resource ("server-d-2" in this case). I'm attaching a screenshot that shows the issue.