Closed Bug 1027903 Opened 10 years ago Closed 10 years ago

Please create a WebOps Request Form in Bugzilla

Categories

(bugzilla.mozilla.org :: Custom Bug Entry Forms, defect, P1)

Production
defect

Tracking

()

RESOLVED FIXED
Due Date:

People

(Reporter: srich, Assigned: dylan)

References

Details

(Keywords: bmo-big)

Attachments

(2 files, 1 obsolete file)

Attached image 20140612_090049.jpg
The WebOps team wants to create a WebOps Request Form in Bugzilla that would take the answers to a number of questions and automatically file a single bug using the contents of the form.

We are trying to improve our ability to respond to requests by simplifying the request while improving our understanding of the request.

Tests:

Given that the new form exists and that a new Component called "WebOps: Request" exists, when the requestor creates a new bug and selects the "Infrastructure & Operations :: WebOps: Request" product/component, the new form will be displayed.

Given that the new form is displayed, only the following field should be displayed:
1. Summary
2. What are you asking us to do?
3. What is the problem you are trying to solve?
4. How would you solve this problem?  How has this problem been solved in the past?
5. Who might be impacted by this change?
6. What are the known dependencies for this request?
7. CC
8. Depends on
9. Blocks

Given that all the fields are displayed, the answers to questions 2, 3, 4, 5, and 6 should be stored in the standard “Description” field, along with their question.  For example:

Description:
What are you asking us to do?
Please renew SSL cert.

Given that the form is filled out, when the requestor presses the “Submit Bug” button the form contents will be saved to a new bug.

Given that the bug is created, the Summary field should be populated (required), the Reporter field should be automatically populated with the email address of the requestor and answers to questions 2 and 3 should be populated (required).  All other field values should be stored as optional in their standard fields.

Please see attached picture for more information about what fields should not be included on the form (x'd out).
Assignee: nobody → dylan
Dylan, I don't want this to block on me if you have questions, so just hit up jakem, gozer or one of the WebOps folks for help if I don't respond. I'm on PTO from Jul 19-27.  Thanks!
Keywords: bmo-big
OS: Mac OS X → All
Priority: -- → P1
Hardware: x86 → All
This is about ready to go up to dev, after I tweak a few minor things.

And a question for dkl:

It is my understanding that forms require a separate entry point -- which means I'm not sure I can do the "when the requestor creates a new bug and selects the "Infrastructure & Operations :: WebOps: Request" product/component, the new form will be displayed" behavior.
Flags: needinfo?(dkl)
(In reply to Dylan William Hardison [:dylan] from comment #2)
> This is about ready to go up to dev, after I tweak a few minor things.
> 
> And a question for dkl:
> 
> It is my understanding that forms require a separate entry point -- which
> means I'm not sure I can do the "when the requestor creates a new bug and
> selects the "Infrastructure & Operations :: WebOps: Request"
> product/component, the new form will be displayed" behavior.

Unfortunately we cannot do it on the component level, just product for now. And it would require a code change in extensions/BMO/lib/Data.pm

http://git.mozilla.org/?p=webtools/bmo/bugzilla.git;a=blob;f=extensions/BMO/Extension.pm;h=b651caf6b80ec8858a93fe2ba2779912beed014e;hb=HEAD#l1211 [github]

FWIW, something that could solve this and other forms should be discussed in bug 1037663 as we need a solution.

dkl
Flags: needinfo?(dkl)
Guys, I'm not fussed.  If I understand correctly, this new form will be presented for all WebOps components?  That's totally workable.  If that's the case, does it make sense to collapse all the components under WebOps into one?
Currently, as it at the Product level rather than the component level, it would have to be presented for everything in the Infrastructure & Operations product -- which is more than just WebOps. Short of moving the WebOps components to a new product (which I am not in favor of) discussing bug 1037663 is the best idea.
The form is up on https://bugzilla-dev.allizom.org/form.webops.request.

Note: The WebOps: Request component is new, so I will need some more information to create it (I created it for bugzilla-dev with bogus description, etc).
The info I need is outlined in this wiki section: https://wiki.mozilla.org/BMO/Requesting_Changes#Components
Flags: needinfo?(srich)
Status: NEW → ASSIGNED
Flags: needinfo?(srich) → needinfo?(nmaul)
Flags: needinfo?(gozer)
Flags: needinfo?(gozer)
Flags: needinfo?(srich)
Is this not needed anymore, or is this just not useful until we implement bug 1037663?
Component: Administration → Custom Bug Entry Forms
Mark/Dylan - apologies for not following up on this sooner.  Let's block it on 1037663.  I think that until we can make this the "one to rule them all", this form won't be used.  I don't want to add cruft.  Meanwhile, we'll work with top requestors to give us the relevant info we need in existing components.  We'll also work to clean up components.
Depends on: 1037663
Flags: needinfo?(srich)
Flags: needinfo?(nmaul)
Status: ASSIGNED → NEW
Bug 1037663 has landed and been deployed.  Any forms for particular components are listed at the top of the "Enter bug" page for the given product (e.g. https://bugzilla.mozilla.org/enter_bug.cgi?product=mozilla.org).

Sean, shall we go ahead with your WebOps form?
Flags: needinfo?(srich)
Mark - thanks for the follow up.  Give me time to get the communications out around this change and then yes, let's make the change.  Question: As people start to use the new form and feedback comes in, does your team have the bandwidth to support tweaking the form as requested?
Flags: needinfo?(srich)
Yes, we should be fix minor issues fairly quickly.  If it's something larger, it might take a week or two, but we'll try to work it in.

Also note that we generally push changes to BMO on a weekly basis, usually Monday night (ET/PT), including any form changes.
It's been so long since I touched this. 
I'll be adding it to the, err, suggested forms list (custom_forms.none.tmpl) and it should be good to go.
Status: NEW → ASSIGNED
Due Date: 2014-11-19
Attached patch bug-1027903-v1.patch (obsolete) — Splinter Review
Finally in for review.

This uses the custom_forms.none.tmpl thing to register this form with the specified component.
Attachment #8538106 - Flags: review?(dkl)
Comment on attachment 8538106 [details] [diff] [review]
bug-1027903-v1.patch

Review of attachment 8538106 [details] [diff] [review]:
-----------------------------------------------------------------

::: extensions/BMO/template/en/default/bug/create/create-webops-request.html.tmpl
@@ +18,5 @@
> +}
> +#webops .field_label {
> +  font-weight: bold;
> +}
> +#webops .field_desc {

Not used

@@ +21,5 @@
> +}
> +#webops .field_desc {
> +  padding-bottom: 3px;
> +}
> +#webops .field_desc,

Not used

@@ +37,5 @@
> +#webops textarea {
> +  font-family: inherit;
> +  font-size: inherit;
> +}
> +#webops em {

Not used

@@ +85,5 @@
> +   style = inline_style
> +   javascript = inline_javascript
> +   javascript_urls = [ 'extensions/BMO/web/js/form_validate.js',
> +                       'js/field.js', 'js/util.js' ]
> +   yui = [ "autocomplete", "calendar", "selector" ]

"calendar" not used

@@ +156,5 @@
> +  <div class="form_section">
> +    <label for="cc" class="field_label">CC</label><br>
> +    [% INCLUDE global/userselect.html.tmpl
> +      id       => "responsible_engineer"
> +      name     => "responsible_engineer"

Change the name and id to "cc", otherwise this value is not stored anywhere.

@@ +159,5 @@
> +      id       => "responsible_engineer"
> +      name     => "responsible_engineer"
> +      value    => ""
> +      size     => 80
> +      classes  => ["bz_userfield"]

add multiple => 5 to allow more than one user to be entered separated by commas.
Attachment #8538106 - Flags: review?(dkl) → review-
I realized all the forms I've done are doing more work than they need to --
I thought the for= attribute of a label referenced the form element name=, rather than id= (durp)
so I use the CSS query bit from YUI to do a rather expensive search to map them to ids. I guess I can fix the other forms i've done eventually. XD

Revised with changes from review.
Attachment #8538106 - Attachment is obsolete: true
Attachment #8540736 - Flags: review?(dkl)
Comment on attachment 8540736 [details] [diff] [review]
bug-1027903-v2.patch

Review of attachment 8540736 [details] [diff] [review]:
-----------------------------------------------------------------

Looks good. r=dkl
Attachment #8540736 - Flags: review?(dkl) → review+
To ssh://gitolite3@git.mozilla.org/webtools/bmo/bugzilla.git
   89e09eb..66a9fc9  master -> master
Status: ASSIGNED → RESOLVED
Closed: 10 years ago
Resolution: --- → FIXED
Blocks: 1118231
Blocks: 1187429
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: