Bug 858299 - Update error text with resolution steps: "Images cannot be built. There are no enabled Cloud Resource Provider Accounts associated with this Cloud. "
Update error text with resolution steps: "Images cannot be built. There are n...
Status: NEW
Product: CloudForms Cloud Engine
Classification: Red Hat
Component: aeolus-conductor (Show other bugs)
All Unspecified
unspecified Severity low
: rc
: ---
Assigned To: Angus Thomas
: FutureFeature, Triaged
Depends On:
  Show dependency treegraph
Reported: 2012-09-18 11:33 EDT by Aaron Weitekamp
Modified: 2013-04-09 14:43 EDT (History)
2 users (show)

See Also:
Fixed In Version:
Doc Type: Enhancement
Doc Text:
Story Points: ---
Clone Of:
Last Closed:
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
screencap: ui error text (96.45 KB, image/jpeg)
2012-09-18 11:33 EDT, Aaron Weitekamp
no flags Details

  None (edit)
Description Aaron Weitekamp 2012-09-18 11:33:15 EDT
Created attachment 614048 [details]
screencap: ui error text

Description of problem:
When creating a new image before adding provider accounts the displayed error provides very little help to the user on how to resolve the issue.

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

How reproducible:

Steps to Reproduce:
1. Nav to Administer -> Clouds
2. Select New Cloud, create cloud
3. Within the cloud just created select New Cloud Resource Zone, create cloud zone 
4. Nav to Administer -> Clouds, within the cloud just created select New Image.
5. observe error
Actual results:
Text displayed: "Images cannot be built. There are no enabled Cloud Resource Provider Accounts associated with this Cloud."

Expected results:
Improved text: "Images cannot be built until at least one Cloud Resource Provider Account is added to this Cloud."
Comment 2 Aaron Weitekamp 2012-09-18 15:35:21 EDT
[root@qeblade41 ~]# rpm -qa |grep aeolus
Comment 3 Mike Orazi 2012-09-19 14:37:39 EDT
We are past string freeze, so I'll move this to 2.0.0.
Comment 4 Aaron Weitekamp 2012-09-19 14:55:42 EDT
I understood there was a compromise: validate the form and display existing message "No blueprint selected." Transcript:

Sep 18 12:49:59 <tzumainn>  aweiteka: one problem - there's no currently existing error message that fits, so creating that message would require a dictionary addition
Sep 18 12:54:07 <aweiteka>  tzumainn, forgive my ignorance... is that significant work? i can't think of another way to deal with this error.
Sep 18 12:54:36 <tzumainn>  yeah, the new dictionary addition would have to be sent to the translators
Sep 18 12:54:55 <tzumainn>  I don't know if there's time built in to do that again
Sep 18 12:56:44 <tzumainn>  there's an existing message that says "no blueprint selected"; the user would still be able to submit the form, but at least the issue would be more explicit
Sep 18 12:57:53 <aweiteka>  tzumainn, where would "no blueprint selected" be displayed? as long as they stay on the form i think that's okay for now
Sep 18 12:58:28 <tzumainn>  it would be displayed on the form, but not until they submitted it
Sep 18 12:59:41 <aweiteka>  tzumainn, that will work. it provides the basic info
Sep 18 13:00:22 <tzumainn>  okay, thanks!
Comment 5 Aaron Weitekamp 2012-09-19 15:10:58 EDT
above comment not related. ignore
Comment 6 Matt Wagner 2013-04-09 14:43:16 EDT
Resetting to default assignee; haven't looked at this in months and it's no longer on my radar.

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