If you think a bug might affect users in the 57 release, please set the correct tracking and status flags for Release Management.

blocking1.9.1 and blocking-fennec fields not working correctly

RESOLVED FIXED

Status

()

bugzilla.mozilla.org
General
--
blocker
RESOLVED FIXED
8 years ago
6 years ago

People

(Reporter: reed, Assigned: justdave)

Tracking

({regression})

Details

Attachments

(1 obsolete attachment)

(Reporter)

Description

8 years ago
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>
(Reporter)

Comment 1

8 years ago
(note the lack of <option>s)
(Reporter)

Updated

8 years ago
Keywords: regression
Priority: -- → P1
We really, really need this fixed.
(Reporter)

Comment 3

8 years ago
Created attachment 412729 [details] [diff] [review]
patch - v1

Possible fix...
Assignee: nobody → reed
Status: NEW → ASSIGNED
Attachment #412729 - Flags: review?(justdave)
Attachment #412729 - Flags: review?(justdave) → review-
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.
sure would make life easy if it did though...
(Reporter)

Comment 6

8 years ago
(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?
Something about it being an object method on the Bug object, and we have no Bug object yet at that point.

Comment 8

8 years ago
(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?).
(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.
Priority: P1 → --
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.
(Reporter)

Updated

8 years ago
Assignee: reed → nobody
(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.
Assignee: nobody → justdave
Status: ASSIGNED → NEW
(Reporter)

Updated

8 years ago
Attachment #412729 - Attachment is obsolete: true
(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

8 years ago
Any update on this?  This is very urgent.

Comment 14

8 years ago
dupe of bug 515214?
(Reporter)

Comment 15

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

Nope, this bug concerns show_bug.cgi, while bug 515214 is about enter_bug.cgi.
(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.
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)
Status: NEW → RESOLVED
Last Resolved: 8 years ago
Resolution: --- → FIXED
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;
Component: Bugzilla: Other b.m.o Issues → General
Product: mozilla.org → bugzilla.mozilla.org
You need to log in before you can comment on or make changes to this bug.