Making next steps/results messaging consistent

[rhamilto]

To Do:

• Update styling of wizard contents once comps are finalized per @ncameronbritt and @jennyhaines

• Implement changes to remove mega alert and show simple bulleted list like create-from-builder-results.html for select from project (wizard) and import (next steps and wizard)

• Display webhook info when appropriate inside wizard results (currently only shows on standalone next steps)

• Show proper type of imported item in import wizard results (non-templates are generically called "YAML / JSON")

• Remove import toast notifications (currently needed for standalone import next steps as it redirects to overview)

• Improve display of provision call failure message
  
  
  
  

• Add appropriate actions when failure occurs

Screenshots:

[spadgett]

Technically this happens even if the user refreshed the next steps page after a failure. We might want a more neutral message.

[spadgett]

Display webhook info when appropriate inside wizard results (currently only shows on standalone next steps)

I think the problem here is that we're just not setting the webhook when not using advanced options. This is arguably just a bug.

[spadgett]

Implement changes to remove mega alert and show simple bulleted list like create-from-builder-results.html for select from project (wizard) and import (next steps and wizard)

I wonder if we shouldn't just change the styling of the tasks component and remove it from the overview.

[ncameronbritt]

Since we have the different webhook options (bitbucket, gitlab), is that something we would want to let users set up as part of this flow, and then show the results on that last step? I'm not sure how common it is that a user would want to set those up.

@jhaines was working on restyling the tasks component, but that's on hold because I was wanting to figure out what a user should do after a partial successes/failure, and what's important for the user to know to take that next step.

[rhamilto]

@spadgett, I think this is ready for review/merge with the understanding we'll tackle the remaining to-dos as follow-ons.

[spadgett]

Since we have the different webhook options (bitbucket, gitlab), is that something we would want to let users set up as part of this flow, and then show the results on that last step? I'm not sure how common it is that a user would want to set those up.

We should probably be consistent in what we set up by default in the dialog vs advanced. There is a checkbox for it in advanced options.

If you are using GitHub, Bitbucket, etc., you probably want them. But if you're not using GitHub and we set up a GitHub webhook for you, that's not helpful. I don't know if we can reliably detect from the Git URL which ones to create.

[spadgett]

Thanks @rhamilto, just one comment

[spadgett]

Remove ng-controller here

[rhamilto]

Comment addressed.

[rhamilto]

We should probably be consistent in what we set up by default in the dialog vs advanced. There is a checkbox for it in advanced options.

And that checkbox is enabled by default. So if you use the wizard, you get no webhook. But if you used advanced with the default, you do. Seems a bit confusing?

[ncameronbritt]

Agree with your comments above re webhooks @spadgett. If it's useful, maybe down the line we can look at adding a step to the wizard or including it in the builder flow some other way.

[spadgett]

[merge]

[openshift-bot]

Evaluated for origin web console merge up to 6f50f95

[openshift-bot]

Origin Web Console Merge Results: SUCCESS (https://ci.openshift.redhat.com/jenkins/job/merge_pull_request_origin_web_console/297/) (Base Commit: 8498bca) (PR Branch Commit: 6f50f95)