528867 - blocking1.9.1 and blocking-fennec fields not working correctly

Status: RESOLVED FIXED

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

Description

[Reed Loden [:reed]]

I was looking at bug 516862, and I noticed blocking1.9.1 and blocking-fennec are both broken.

Here's an example:

    <tr><th class="field_label "
      id="field_label_cf_blocking_191">
      <label for="cf_blocking_191">blocking1.9.1:</label>

  </th>

<td class="field_value "
    id="field_container_cf_blocking_191"  colspan="2">
        <select id="cf_blocking_191" 
                name="cf_blocking_191" 
                >
        </select>
        

        <script type="text/javascript">
        <!--
          initHidingOptionsForIE('cf_blocking_191');
          
        //-->
        </script>
</td>
    </tr>

Comment 1

[Reed Loden [:reed]]

(note the lack of <option>s)

Comment 2

[Samuel Sidler (old account; do not CC)]

We really, really need this fixed.

Comment 3

[Reed Loden [:reed]]

Attachment: patch - v1

Possible fix...

Comment 4

[Dave Miller [:justdave]]

Comment on attachment 412729 [details] [diff] [review]
patch - v1

As much as I'd love it if that worked, it doesn't.  check_can_change_field can't be used from enter_bug.cgi, and this template is used in both places.

Comment 5

[Dave Miller [:justdave]]

sure would make life easy if it did though...

Comment 6

[Reed Loden [:reed]]

(In reply to comment #4)
> (From update of attachment 412729 [details] [diff] [review])
> As much as I'd love it if that worked, it doesn't.  check_can_change_field
> can't be used from enter_bug.cgi, and this template is used in both places.

We should just fix that. Is there an upstream bug filed on that? Why exactly can't it be used from enter_bug.cgi?

Comment 7

[Dave Miller [:justdave]]

Something about it being an object method on the Bug object, and we have no Bug object yet at that point.

Comment 8

[Frédéric Buclin]

(In reply to comment #6)
> We should just fix that. Is there an upstream bug filed on that? Why exactly
> can't it be used from enter_bug.cgi?

You cannot use it for new bugs because it's named check_can_change_field(), which is irrelevant when the bug doesn't exist yet (how can you *change* something which doesn't exist?).

Comment 9

[Dave Miller [:justdave]]

(In reply to comment #8)
> You cannot use it for new bugs because it's named check_can_change_field(),
> which is irrelevant when the bug doesn't exist yet (how can you *change*
> something which doesn't exist?).

Well, in this specific use case...  :)  We want to know if the user could change it if it did exist.  This seems like a logical way to consolidate that type of answer.  As it stands now, we have to put the description of who's allowed to change the field in three different places to work around the lack of this function working on the new bug page (once in check_can_change_field to prevent people from hacking the system, and one in each of the show_bug and enter_bug templates that use the field).  If we could use this from enter_bug, then the check_can_change_field definition would be the only one we need.

Comment 10

[Samuel Sidler (old account; do not CC)]

Can we not do a full, real solution in this bug and instead just return to how things were, however hacked together? This issue is causing problems right now.

Comment 11

[Samuel Sidler (old account; do not CC)]

(In reply to comment #10)
> This issue is causing problems right now.

To be more clear: People being unable to request blocking and alert drivers to blocking issues can and will adversely affect the quality of Firefox. In this case, Firefox 3.5.6.

Comment 12

[Dave Miller [:justdave]]

(In reply to comment #11)
> (In reply to comment #10)
> > This issue is causing problems right now.
> 
> To be more clear: People being unable to request blocking and alert drivers to
> blocking issues can and will adversely affect the quality of Firefox. In this
> case, Firefox 3.5.6.

releases-rsync being devoid of content has my priority at the moment.  I probably will get to this later tonight though.

Comment 13

[Stuart Parmenter]

Any update on this?  This is very urgent.

Comment 14

[Frédéric Buclin]

dupe of bug 515214?

Comment 15

[Reed Loden [:reed]]

(In reply to comment #14)
> dupe of bug 515214?

Nope, this bug concerns show_bug.cgi, while bug 515214 is about enter_bug.cgi.

Comment 16

[Dave Miller [:justdave]]

(In reply to comment #13)
> Any update on this?  This is very urgent.

Working on it right now, never made it last night because of the stage upgrade madness.  Hopefullt will have it figured out shortly.

Comment 17

[Dave Miller [:justdave]]

finally.  (sorry for the wait).

modified Bugzilla/Bug.pm
modified template/en/default/bug/field.html.tmpl
modified template/en/default/bug/create/create.html.tmpl
Committed revision 6712.
should be live later this morning (got a few other things going in with it)

Comment 18

[Dave Miller [:justdave]]

OK, that fix turned out to not be complete.  Fixed version:

modified enter_bug.cgi
modified template/en/default/bug/field.html.tmpl
Committed revision 6714.

fwiw, I did end up fixing enter_bug.cgi so check_can_change_field could be used from there.  Yes, it's a hack, but it's less hacky than it sounds. :)

=== modified file 'enter_bug.cgi'
--- enter_bug.cgi       2009-11-19 05:30:36 +0000
+++ enter_bug.cgi       2009-11-21 09:53:48 +0000
@@ -619,4 +619,8 @@
 Bugzilla::Hook::process("enter_bug-entrydefaultvars", { vars => $vars });
 
+# hack to allow the bug entry templates to use check_can_change_field to see if
+# various field values should be available to the current user
+$default{'check_can_change_field'} = sub { return Bugzilla::Bug::check_can_change_field(\%default, @_) };
+
 $vars->{'default'} = \%default;