Bug 705713 - Templates not honored for resource-config when creating a new resource
Summary: Templates not honored for resource-config when creating a new resource
Status: CLOSED CURRENTRELEASE
Alias: None
Product: RHQ Project
Classification: Other
Component: Core UI
Version: 4.0.0
Hardware: Unspecified
OS: Unspecified
high
high vote
Target Milestone: ---
: ---
Assignee: Charles Crouch
QA Contact: Mike Foley
URL:
Whiteboard:
Keywords:
Depends On:
Blocks: jon3 jon3-sprint1 715334 rhq41 rhq41-ui
TreeView+ depends on / blocked
 
Reported: 2011-05-18 08:31 UTC by Heiko W. Rupp
Modified: 2015-02-01 23:26 UTC (History)
5 users (show)

(edit)
Clone Of:
(edit)
Last Closed: 2013-09-03 17:00:35 UTC


Attachments (Terms of Use)
step 1 (21.34 KB, image/png)
2011-05-18 08:31 UTC, Heiko W. Rupp
no flags Details
step 2 (19.55 KB, image/png)
2011-05-18 08:31 UTC, Heiko W. Rupp
no flags Details


External Trackers
Tracker ID Priority Status Summary Last Updated
Red Hat Bugzilla 729994 None None None Never

Internal Trackers: 729994

Description Heiko W. Rupp 2011-05-18 08:31:15 UTC
Created attachment 499542 [details]
step 1

Have the following in a plugin descriptor:


            <resource-configuration>
                <c:list-property name="entries" required="false"  readOnly="true"
                                 description="The jndi names the queue will be bound to.">
                    <c:simple-property name="entries" type="string"/>
                </c:list-property>
                <c:template name="add" description="Template when adding a Topic">
                    <!--<c:list-property name="entries" required="false"-->
                                     <!--description="The jndi names the queue will be bound to.">-->
                        <c:simple-property name="entries" type="string"/>
                    <c:simple-property name="foobar" required="false" />
                    <!--</c:list-property>-->
                </c:template>
            </resource-configuration>

This is some property and then a template with the name "add".

I can select the template in the 1st step of the wizard, but the 2nd step seems to always display the 'default template' ( the section of the config outside the 'c:template' tag).

Comment 1 Heiko W. Rupp 2011-05-18 08:31:40 UTC
Created attachment 499543 [details]
step 2

Comment 2 Heiko W. Rupp 2011-08-08 11:04:08 UTC
I think the issue may be here:

org.rhq.enterprise.gui.coregui.client.inventory.resource.factory.AbstractResourceFactoryWizard#setNewResourceConfigurationDefinition

As this is always using the default template and not the one the user
selected in the step before
.. = this.newResourceConfigurationDefinition.getDefaultTemplate()...

Comment 3 Heiko W. Rupp 2011-08-08 14:00:57 UTC
[15:34:59] <jshaughn> well, there is a bug, minimally with previous/next behavior
[15:37:05] <jshaughn> but the workaround would be cancel and reinvoke the wizard.
[15:39:59] <pilhuhn> I have
[15:40:09] <pilhuhn> <resource-configuration>
[15:40:09] <pilhuhn>                <c:simple-property name="profile" description="The profile name" required="true"/>
[15:40:10] <pilhuhn> ...
[15:40:20] <pilhuhn>         <c:template name="foo" description="just a demo">
[15:40:20] <pilhuhn>                    <c:simple-property name="bla bla"/>
[15:40:20] <pilhuhn>                    <c:simple-property name="hulla"/>
[15:40:20] <pilhuhn>                </c:template>
[15:40:20] <pilhuhn>            </resource-configuration>
[15:41:06] <jshaughn> fyi: I'm testing with the RHQ Server DataSource type
[15:41:09] <pilhuhn> THis nicely shows "default" and "foo" in the dropdown. When I select 'foo', in the next step the default properties are shown and not the ones from "foo"
[15:41:24] <pilhuhn> that is for create child resources
[15:42:50] <jshaughn> can you try DataSource and see what you see. Because that is not what I'm seeing.  If I select XA I do see XA seeded in the config editor
[15:45:02] <pilhuhn> Indeed
[15:45:57] <pilhuhn> - the RHQ code fails silently with my stuff without telling
[15:47:01] <jshaughn> really, so  a silent failure of a plugin metadata issue?
[15:47:36] <pilhuhn> the way I do it is accepted by the plugin and UI
[15:48:11] <pilhuhn> I see that the default properties in Datasources are all grouped. I only have ungrouped ones - that may be the difference

Comment 4 Charles Crouch 2011-08-11 03:47:13 UTC
Is this still blocking you Heiko?

Comment 5 Heiko W. Rupp 2011-08-11 09:05:53 UTC
No, not directly - this BZ itself is probably even invalid as I was misunderstanding the templates

Nevertheless:

- Jay wanted to fix a minor issue:  back/next issue he found

- Ian wanted to enable making read-only properties writable when used in CreateChild dialogs

The latter would probably the solution to the issue I am running in the as7 plugin.

Comment 6 Charles Crouch 2011-08-11 12:22:44 UTC
Jay, can you comment on whether the issue Heiko is referrring to is fixed. If 
not, please raise a BZ

Comment 7 Charles Crouch 2011-08-11 12:22:50 UTC
Ian, can you comment on whether the issue Heiko is referrring to is fixed. If 
not, please raise a BZ

Comment 8 Jay Shaughnessy 2011-08-11 13:57:00 UTC
The bug you ask about is not fixed.  I've added a link to the new BZ, 729994, which I've initially set to medium/medium and not blocking anything.

Comment 9 Jay Shaughnessy 2011-08-21 18:02:19 UTC
The BZ I created related to this, 729994 [Create/Import wizard does not
allow reselection of template], has been  set to ON_QA.

I'm not sure if there is more work to be done on this original BZ. I'm
not sure where things stand related to the read-only property
work mentioned above.  Asking ian to take a look and take over if
necessary.

Comment 10 Ian Springer 2011-08-22 22:21:22 UTC
[master ff5bb9e] - always make all properties, even read-only ones, writable in the config editors in the create-resource and import-resource wizards

Comment 11 Sunil Kondkar 2011-08-25 10:45:14 UTC
Verified on build#344 (Version: 4.1.0-SNAPSHOT Build Number: bdc6f5e)

Verified on import and create child wizards. All the properties are writable.
Marking as verified.

Comment 13 Heiko W. Rupp 2013-09-03 17:00:35 UTC
Bulk closing of old issues that are in VERIFIED state.


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