Note: This bug is displayed in read-only format because the product is no longer active in Red Hat Bugzilla.

Bug 640257

Summary: Add Account issues
Product: [Retired] CloudForms Cloud Engine Reporter: Shveta <ssachdev>
Component: aeolus-conductorAssignee: Tomas Sedovic <tsedovic>
Status: CLOSED CURRENTRELEASE QA Contact: wes hayutin <whayutin>
Severity: medium Docs Contact:
Priority: low    
Version: 0.3.1CC: cpelland, deltacloud-maint, sseago, tsedovic, whayutin
Target Milestone: alphaFlags: tsedovic: needinfo+
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 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: 642820    
Attachments:
Description Flags
Tool tip message
none
Account without providing mandatory fields none

Description Shveta 2010-10-05 11:06:54 UTC
Description of problem:


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


How reproducible:


Steps to Reproduce:
1. Add provider - "ec2"
2. Add account 
3. Provide all fields and Save .
Account gets added.
  
Actual results:


Expected results:


Additional info:

1) Reset button doesn't work.
2) Remove the added account.
  Add the account again with Mandatory field " Account name " empty 
  account gets added.
3) Now give account number empty (which is also manadatory) . account gets added
4) Dont upload keys , account gets added.
5) The tool tip (when we take cursor to the field) shows a big message for Account number and password (something like -<span class="translation missing">)
6) Clicking on "Unlimited Quota " doesn't do anything.

Comment 1 Scott Seago 2010-10-05 14:52:22 UTC
Yes I'm not sure what the "unlimited quota" link is suppposed to do. If you want quota unlimited all you have to do is leave the quota field blank, and it will be unlimited (if you leave the string 'unlimited' there it should also remain unlimited)

Comment 2 Shveta 2010-10-06 04:12:05 UTC
Created attachment 451795 [details]
Tool tip message

Comment 3 Shveta 2010-10-06 04:13:36 UTC
Created attachment 451796 [details]
Account without providing mandatory fields

Account without providing mandatory fields

Comment 4 Tomas Sedovic 2010-10-20 09:30:12 UTC
Scott, it is not immediately obvious that leaving the quota field blank would set it to no limit. Especially since the quota field is marked as "required".

This link should help with that. Clicking on it sets the quota to the "unlimited" state.

Shveta, to test the functionality, enter a number into the "Quota Instances" field and then press the "Unlimited Quota" link.

Maybe we should change the text to "Set Unlimited Quota" to make it clearer, though.

For the rest of the comments, I've sent the fix in this thread:

https://fedorahosted.org/pipermail/deltacloud-devel/2010-October/002927.html

Comment 5 Scott Seago 2010-10-20 13:17:12 UTC
Does the fix still preserve the behavior where leaving it blank makes it unlimited as well? We should probably remove the "required" marking and still allow an empty quota, although the explicit "unlimited" string should also work.

Comment 6 Tomas Sedovic 2010-10-22 19:53:03 UTC
Fixed in commits:

2f6b6f9
fbc805f
69e917a


Scott, yes the blank field for quota still works.

Comment 7 Shveta 2010-10-25 06:35:29 UTC
Above issues are fixed.
However , Reset button still doesn't work.

Quota field : Enter any number and click on "Unlimited Quota" and save .
Unlimited Quota is saved.

Enter Blank and Save , Unlimited Quota is saved.
Working Fine .

Please let me know about 'Reset ' also if it will be done in phase 1.

Comment 8 Tomas Sedovic 2010-11-02 15:36:43 UTC
Shveta,

what exactly is wrong with the Reset button, pleas? Here's what I did:

1, add a provider and a provider account
2, enter new values to the existing account fields
3, press Reset

The account was not updated and the entered values were replaced by the original ones.

That is the expected behaviour (unless you disagree) and it works for me.

Comment 9 Shveta 2010-11-08 05:45:57 UTC
Works fine.

Comment 10 wes hayutin 2011-08-01 19:58:33 UTC
release pending...

Comment 11 wes hayutin 2011-08-01 19:59:30 UTC
release pending...

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

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