Closed Bug 895687 Opened 11 years ago Closed 11 years ago

The product tracking team would like a way to have a clear definition of a user story in a bug

Categories

(bugzilla.mozilla.org :: General, defect)

Production
defect
Not set
normal

Tracking

()

RESOLVED FIXED

People

(Reporter: cmtalbert, Assigned: glob)

References

Details

Attachments

(1 file, 1 obsolete file)

Here is what they are asking for:
1. An editable field (possibly an editable comment field - comment 0)
2. That is only available in the "Tracker" product
3. They would use this field to write and hone the user story that the bug refers to.  And this editable field would always reflect the current, most up to date version of the user story.

Essentially this allows someone to look at a bug at a glance and know exactly what the story is without having to read through all the comments on the bug.  This could be generally useful, I know, but let's focus on the specific use case here since that helps scope the issue.

Some additional things that they would like (in priority order)
* The ability to lock the editable field so that only the reporter has the ability to change it. Not a requirement, but a nice to have.
* The ability to track the history of the editable field so that folks know what the user story field said 3 weeks ago, for instance.

I've marked this dependent on the "user story" bug that the product team created for us so you can get a sense of how this works in practice (and can see Caitlin's detailed writeup).

Can we get a rough sizing of this ask (just the editable field on the tracking product)?  From there we can see how it fits in with our other current priorities.
here's some thoughts on implementation:
- there is already a custom field type "large text box" which should be suitable
- we'd need custom code to change its placement on the show_bug and create_bug pages
- per-product visibility and restrictions on who can edit are trivial to implement
- we'd probably want inline history changed to not show the full text when this field is
  updated, instead just show that it was touched

i would expect this to take less than a week, however it would take longer should bugzilla's native "large text box" field pan out to be unsuitable.

that said, i'm not completely comfortable with adding a mediumtext field to the bugs table until we've cut down on the number of custom fields already present (168 custom bug fields currently, all on the same table).
(In reply to Byron Jones ‹:glob› from comment #1)
> that said, i'm not completely comfortable with adding a mediumtext field to
> the bugs table until we've cut down on the number of custom fields already
> present (168 custom bug fields currently, all on the same table).
So, everything sounded pretty good up to this point. ;-)  When do you expect to be able to clear enough space in order to add a field like this to the Bugs table? This sounds like it's tied up with the tracking flags migration work. I'm not clear how many tracking flags have to be moved to the new set up in order to free up enough fields to make adding this field viable.
(In reply to Clint Talbert ( :ctalbert ) from comment #2)
> So, everything sounded pretty good up to this point. ;-)  When do you expect
> to be able to clear enough space in order to add a field like this to the
> Bugs table?

unfortunately not until the next IT outage window (in about 6 weeks).

> This sounds like it's tied up with the tracking flags migration
> work. I'm not clear how many tracking flags have to be moved to the new set
> up in order to free up enough fields to make adding this field viable.

it isn't a case of "moving enough fields" as the fields need to be migrated all at the same time.
Attached patch 895687_1.patch (obsolete) — Splinter Review
first revision.  features:
- adds 'user story' textarea above the first comment
  - styled slightly different from comments
  - displayed as linkified text first, clicking (edit) changes it to a textarea
- visible on the "tracking" product only
- the story is visible to everyone
- you must be in the editbugs group to be able to edit the story
- instead of a full "old value" // "new value" being inserted into the bug's
  history, a unified diff with 0 lines of context is inserted
- the inline history extension just displays "User Story: updated" when the
  field is changed
Attachment #808633 - Flags: review?(dkl)
(In reply to Byron Jones ‹:glob› from comment #4)
> Created attachment 808633 [details] [diff] [review]
> 895687_1.patch
> 
> first revision.  features:
> - adds 'user story' textarea above the first comment
>   - styled slightly different from comments
>   - displayed as linkified text first, clicking (edit) changes it to a
> textarea
> - visible on the "tracking" product only
> - the story is visible to everyone
> - you must be in the editbugs group to be able to edit the story
> - instead of a full "old value" // "new value" being inserted into the bug's
>   history, a unified diff with 0 lines of context is inserted
> - the inline history extension just displays "User Story: updated" when the
>   field is changed
This sounds like a great version 1 for this feature. I think it's actually a version 1.5 or 2 based on the original ask. Thanks!
Assignee: nobody → glob
Comment on attachment 808633 [details] [diff] [review]
895687_1.patch

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

::: extensions/InlineHistory/Extension.pm
@@ +58,5 @@
>      }
>  
> +    # allow other extensions to alter history
> +    Bugzilla::Hook::process('inline_history_activtiy', { activity => $activity });
> +

weeee, extensions calling extension hooks :) This is the first one from the perl modules that I can tell. We have done it from templates for long time.

::: extensions/UserStory/Extension.pm
@@ +36,5 @@
> +    my $group = $bug->product_obj->user_story_group()
> +        || return;
> +    if (!$user->in_group($group)) {
> +        push (@$priv_results, PRIVILEGES_REQUIRED_EMPOWERED);
> +    }

You need to check that $field eq 'cf_user_story' as well.

::: extensions/UserStory/lib/Data.pm
@@ +16,5 @@
> +
> +our $user_story_products = {
> +    # product   group required to edit
> +    Tracking    => 'editbugs',
> +};

Nit: Better as a constant and rename to Constants.pm?

::: extensions/UserStory/template/en/default/hook/bug/show-header-end.html.tmpl
@@ +5,5 @@
> +  # This Source Code Form is "Incompatible With Secondary Licenses", as
> +  # defined by the Mozilla Public License, v. 2.0.
> +  #%]
> +
> +[% style_urls.push("extensions/UserStory/web/user_story.css") %]

Nit: extensions/UserStory/web/user_story.css => extensions/UserStory/web/styles/user_story.css

::: template/en/default/bug/activity/table.html.tmpl
@@ +110,4 @@
>                 change.fieldname == 'flagtypes.name' %]
>          [% display_value(change.fieldname, change_type) FILTER email FILTER html %]
>        [% ELSE %]
> +        [% display_value(change.fieldname, change_type) FILTER html_br %]

Push this upstream as well? Seems like a good idea.
Attachment #808633 - Flags: review?(dkl) → review-
Depends on: 929348
Attached patch 895687_2.patchSplinter Review
i've file bug 929345 for the upstream implementation of html_br.  i've left the code for that in this patch so we're not blocked by upstream for this bug.
Attachment #808633 - Attachment is obsolete: true
Attachment #820174 - Flags: review?(dkl)
Comment on attachment 820174 [details] [diff] [review]
895687_2.patch

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

r=dkl
Attachment #820174 - Flags: review?(dkl) → review+
Committing to: bzr+ssh://bjones%40mozilla.com@bzr.mozilla.org/bmo/4.2/
modified Bugzilla/Bug.pm
modified Bugzilla/Template.pm
added extensions/UserStory
modified extensions/InlineHistory/Extension.pm
added extensions/UserStory/Config.pm
added extensions/UserStory/Extension.pm
added extensions/UserStory/lib
added extensions/UserStory/template
added extensions/UserStory/web
added extensions/UserStory/lib/Constants.pm
added extensions/UserStory/template/en
added extensions/UserStory/template/en/default
added extensions/UserStory/template/en/default/hook
added extensions/UserStory/template/en/default/hook/bug
added extensions/UserStory/template/en/default/hook/bug/comments-comment_banner.html.tmpl
added extensions/UserStory/template/en/default/hook/bug/edit-custom_field.html.tmpl
added extensions/UserStory/template/en/default/hook/bug/show-header-end.html.tmpl
added extensions/UserStory/web/style
added extensions/UserStory/web/style/user_story.css
modified t/008filter.t
modified template/en/default/bug/activity/table.html.tmpl
Committed revision 9092.
Status: NEW → RESOLVED
Closed: 11 years ago
Resolution: --- → FIXED
This is so awesome - excited!!! Thank you so much for putting this work in.
I don't see it yet live - is there a period of time before the change will be live?


Thanks again!!!
Flags: needinfo?(glob)
Code changes are generally pushed out to production on Wednesday nights, so you should see it tomorrow morning.  It is live on our staging server right now (bugzilla.allizom.org), to which you should have access, if you are anxious to see a preview. :)
Flags: needinfo?(glob)
this change is now live on production.
Blocks: 963793
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: