Bug 713010 - Changing provider type in New Provider Account page causes error
Summary: Changing provider type in New Provider Account page causes error
Keywords:
Status: CLOSED CURRENTRELEASE
Alias: None
Product: CloudForms Cloud Engine
Classification: Retired
Component: aeolus-conductor
Version: 0.3.1
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: rc
Assignee: Chris Lalancette
QA Contact: wes hayutin
URL:
Whiteboard:
Depends On:
Blocks: ce-p2-beta-fixed
TreeView+ depends on / blocked
 
Reported: 2011-06-13 21:53 UTC by Matt Wagner
Modified: 2014-08-17 22:27 UTC (History)
9 users (show)

Fixed In Version:
Clone Of:
Environment:
Last Closed:
Embargoed:


Attachments (Terms of Use)
Screenshot after changing provider type in dropdown (295.57 KB, image/png)
2011-06-13 21:54 UTC, Matt Wagner
no flags Details
on_clicking_add (248.67 KB, image/png)
2011-06-14 05:08 UTC, Shveta
no flags Details
ss (91.03 KB, image/png)
2011-06-16 17:45 UTC, wes hayutin
no flags Details

Description Matt Wagner 2011-06-13 21:53:22 UTC
Description of problem:

When you are on the "New Provider Account" page, if you use the dropdown to change the provider type, that section of the page is replaced by ProviderAccounts#index, seemingly the full page including headers. (See attached screenshot.)

It seems like it's returning a full HTML document instead of a partial, but I haven't been able to look into this yet.


Version-Release number of selected component (if applicable):
This is happening at the tip of next, and in the -testing RPMs. 2a5a633ab6b7106725835d93ddfb116e8e52d204 is the most recent commit.


How reproducible:
100%

Steps to Reproduce:
1. As an administrator, go to the Provider Accounts page
2. Click "New Provider Account"
3. Change the value in the "Provider" dropdown to anything else.
  
Actual results:
List of provider accounts is shown


Expected results:
Form is updated to show correct fields for that provider.


Additional info:

Comment 1 Matt Wagner 2011-06-13 21:54:10 UTC
Created attachment 504555 [details]
Screenshot after changing provider type in dropdown

Comment 2 Shveta 2011-06-14 05:08:23 UTC
Created attachment 504590 [details]
on_clicking_add

On selecting any provider the page displays an ADD button. 
Clicking on Add button displays the following error .
undefined method `[]' for nil:NilClass 


Screenshot attached.

Comment 3 Matt Wagner 2011-06-14 13:57:23 UTC
FYI, there's also an overlapping Redmine task for this bug: https://www.aeolusproject.org/redmine/issues/1761

Comment 4 Chris Lalancette 2011-06-14 17:24:44 UTC
*** Bug 713005 has been marked as a duplicate of this bug. ***

Comment 5 Chris Lalancette 2011-06-14 17:31:23 UTC
So I've been looking at this with my almost non-existent javascript knowledge.  Here's what I see happening:

When you click on the drop-down in the provider accounts page, there is a piece of javascript that gets invoked to reload the page with appropriate UI elements.  This piece of javascript looks like this:

   $(document).ready(function(){
        var selected_provider;
        $("#provider_account_provider_id").change(function()
        {
            selected_provider = $("option:selected").attr('value');
            $.get("https://lemur.usersys.redhat.com/conductor/provider_accounts/set_selected_provider", {'provider_account[provider_id]':selected_provider},
              function(result) {
                $("#provider_type").html(result);
              }
            );
    
         });
    });

However, notice that it is an anonymous function, and further notice that it is loaded on .ready().  From what I've read, that means it gets loaded in during page load time.

The next part is what I'm not really sure about.  I think what happens is that during a click on the drop-down, a "change" event gets sent, which invokes this piece of javascript.  But the problem is that option:selected isn't specific enough; it doesn't mention which form that we should be choosing this option from.  I believe what happens is that it actually takes the selected element of the *first* form on the page, which happens to be admin-select drop-down.  It then uses the value of that (which is /conductor/user) as the account_id, and things go down from there.

While the details of the preceding paragraph might not be 100% correct, the output in the rails process does bear out the results:

Processing ProviderAccountsController#set_selected_provider (for 10.16.19.47 at 2011-06-14 12:15:31) [GET]
  Parameters: {"action"=>"set_selected_provider", "controller"=>"provider_accounts", "provider_account"=>{"provider_id"=>"/conductor/users"}}

That provider_account[provider_id] is totally bogus.  I'm not quite sure how to fix this yet.

Chris Lalancette

Comment 6 Chris Lalancette 2011-06-14 17:53:05 UTC
Got it.  The javascript just needs a tweak to pull from the right select statement.  I'll be posting a patch presently.

Chris Lalancette

Comment 7 Jozef Zigmund 2011-06-16 14:35:06 UTC
Bugfix in git repo, commit hash 299144cc793a9dd821755360a3965faa06245ccc

Comment 8 wes hayutin 2011-06-16 17:45:50 UTC
Created attachment 505108 [details]
ss

This is fixed in 
[root@ibm-x3650-03 ~]# rpm -qa | grep aeolus
aeolus-conductor-devel-0.3.0-0.el6.20110616154040gited9b37c.noarch
aeolus-configure-2.0.1-0.el6.20110602110128git5cb9257.noarch
aeolus-conductor-0.3.0-0.el6.20110616154040gited9b37c.noarch
aeolus-conductor-daemons-0.3.0-0.el6.20110616154040gited9b37c.noarch
aeolus-conductor-doc-0.3.0-0.el6.20110616154040gited9b37c.noarch
aeolus-all-0.3.0-0.el6.20110616154040gited9b37c.noarch
[root@ibm-x3650-03 ~]# 

able to create provider accounts for both us-east and us-west
changing the combo box does cause an error

Comment 9 wes hayutin 2011-07-05 15:04:14 UTC
removing ce-p2-beta

Comment 10 wes hayutin 2011-07-05 15:07:58 UTC
second attempt to remove ce-p2-beta

Comment 11 wes hayutin 2011-08-01 19:58:38 UTC
release pending...

Comment 12 wes hayutin 2011-08-01 19:59:33 UTC
release pending...

Comment 14 wes hayutin 2011-12-08 13:58:59 UTC
closing out old bugs

Comment 15 wes hayutin 2011-12-08 14:11:41 UTC
perm close


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