Bug 535056 - (RHQ-1792) inputs for unset optional props are no longer disabled as they should be after an open map member prop is deleted via DELETE button
inputs for unset optional props are no longer disabled as they should be afte...
Status: CLOSED WONTFIX
Product: RHQ Project
Classification: Other
Component: Configuration (Show other bugs)
1.1.2
All All
medium Severity medium (vote)
: ---
: ---
Assigned To: Ian Springer
http://jira.rhq-project.org/browse/RH...
: SubBug
Depends On:
Blocks: rhq_triage
  Show dependency treegraph
 
Reported: 2009-03-16 18:54 EDT by Ian Springer
Modified: 2013-08-05 20:33 EDT (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
r3440
Last Closed: 2010-08-20 11:22:36 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Ian Springer 2009-03-16 18:54:00 EDT
The problem is that the JavaScript "prepareInputsForSubmission(this)", which is in the form's onsubmit attribute, is never called. This happens because the JavaScript from the form's onsubmit attribute is not called when the form is submitted via a commandLink, rather than a commandButton, and the DELETE button is a commandLink. So I figured I would try using the commandLink's onclick attribute to call prepareInputsForSubmission(), i.e. onclick="return prepareInputsForSubmission(this.form);". This almost works, but for some reason, the commandLink's child params are not included in the request that is submitted, and therefore the delete ends up being a no-op. Note, the reason commandLink was used rather than commandButton in the first place is because commandButton does not support child f:params, which were necessary for the DELETE button; a possible alternative is to use a commandButton and f:attributes, which are supported by both commandLinks and commandButtons.

I spent several hours troubleshooting this and wasn't able to get it to work. I think it should be tabled until post-x.2. The workaround is to uncheck and then recheck the Unset checkboxes for any optional integer props before clicking SAVE to update the config. Otherwise, you will see validation errors for those props saying "" is not a valid value for integer property 'foobar'.
Comment 1 Joseph Marques 2009-03-16 21:19:16 EDT
ian, what are the things we modeled as open map props today across all plugins?  i'm trying to get a sense for how often end users will see this.  if this is open map type is used for any common and/or important config props, i would want to get a proper fix into x.2 release.

as for the problem itself, what happens if the commandLink makes the change, and then *redirects* back to the same page?  if things are in the seam conversation (and they are) would this just naturally work instead of trying to get a javascript-based solution to work?
Comment 2 Red Hat Bugzilla 2009-11-10 15:46:45 EST
This bug was previously known as http://jira.rhq-project.org/browse/RHQ-1792
Comment 3 wes hayutin 2010-02-16 11:56:44 EST
Temporarily adding the keyword "SubBug" so we can be sure we have accounted for all the bugs.

keyword:
new = Tracking + FutureFeature + SubBug
Comment 4 wes hayutin 2010-02-16 12:02:01 EST
making sure we're not missing any bugs in rhq_triage
Comment 5 Corey Welton 2010-08-20 11:15:26 EDT
Closing per 19-Aug triage -- this bug will be made obsolete per UI redesign.

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