709818 - a user should be able to create a product first, and environments later

Status: RESOLVED WONTFIX

(Mozilla QA Graveyard :: MozTrap, enhancement)

Description

[Cameron Dawson [:camd]]

When a person first starts setting up Case Conductor, it's more natural to think of the products you want to test first rather than the environments to test them in.

Therefore it would make more sense to be able to create your products, without setting the env profile.  Then you create your env profiles.  The user can't activate a product until it has an env profile.

Bonus points: it would be nice to have a way for the user, while creating their Product to be able to either select an existing profile, or create a new one.  Could the drop down just have an element that says "Create new Environment profile upon saving" ?  And when they click save on the Product create screen, they're taken to the env profile creation area, and they create the profile, then it's added to the product they came from?

Comment 1

[Cameron Dawson [:camd]]

A Pivotal Tracker story has been created for this Bug: http://www.pivotaltracker.com/story/show/22545801

Comment 2

[Cameron Dawson [:camd]]

Carl Meyer changed story state to started in Pivotal Tracker

Comment 3

[Cameron Dawson [:camd]]

Carl Meyer changed story state to unstarted in Pivotal Tracker

Comment 4

[Cameron Dawson [:camd]]

Cameron Dawson added a comment in Pivotal Tracker:   
   
I think this might just need to have an "Env Template" (profile) field added to the edit product page.  And perhaps if runs are added for this product, they can't be activated until you set an env template?

Comment 5

[Cameron Dawson [:camd]]

Carl Meyer added a comment in Pivotal Tracker:   
   
Product version, not product. And should that field only be added if the product version currently has no environments? Or if it already has some, would the template ones just get added to the ones it already has?

Can you create another story for "prevent activating a run if it has no environments"? That'll cover the second part. If envs are added to the product version, they'll cascade down to the draft run automatically.

Comment 6

[Cameron Dawson [:camd]]

Cameron Dawson added a comment in Pivotal Tracker:   
   
OK, I'm thinking this through a little better now.  Thanks for the clarification, Carl.  

1. I think we should have a default env template of "Any" or something to that effect.  (Carl and I talked about this at one point) The single category and element could both be called "Any" I guess.
2. The env template choice for a new product defaults to "Any"
3. When the user goes into the Product Version edit page and clicks "select environments" they get the usual env edit page and can update from there.  
4. I can add a story for the env edit page to let you (if you're editing a Prod Version) select a template and either replace or append to what you currently have.  That page should probably also detect that if the user has deleted ALL the envs from the PV, then it adds the "Any" back in for them.
5. So no need to prevent activating a run, since it will always at least have "Any"

thoughts?

Comment 7

[Cameron Dawson [:camd]]

Carl Meyer added a comment in Pivotal Tracker:   
   
I think something like this could work. Rather than the complexity of trying to automatically add/remove the "Any" environment at the product version level, what I think I would do is just allow product versions to have no environments (and maybe display "Any" as the environment if there are none, so it appears it's there to the user).  I would only actually add the Any environment to a run if a run is activated and has no environments otherwise. But yeah, basically the same effect.

Comment 8

[Cameron Dawson [:camd]]

Cameron Dawson added a comment in Pivotal Tracker:   
   
changing story title/purpose.  formerly was: "a user should be able to create a product first, and environments later"

Comment 9

[Stephen Donner [:stephend] Not actively reading bugmail]

Mass-closing remaining MozTrap bugs as WONTFIX, due to 1) the Mozilla-hosted instance being decommissioned (see https://wiki.mozilla.org/TestEngineering/Testrail), and, for now, 2) the still-up code archived at its GitHub page: https://github.com/mozilla/moztrap (we'll decide what's next for that, in the near future).

See also the history and more-detailed discussion which led us here, at https://groups.google.com/forum/#!topic/mozilla.dev.quality/Sa75hV8Ywvk

(If you'd like, you should be able to filter these notification emails using at least the unique string of "Sa75hV8Ywvk" in the message body.

Thanks!