192898 - After upgrading to 2.17.3 all bugs in buglist have a lightgray background

Status: RESOLVED WORKSFORME

(Bugzilla :: Query/Bug List, defect)

Description

[Andreas Otte]

After upgrading to 2.17.3 from 2.17 all bugs in buglist have a lightgray
background. The problem seems to be in table.html.tmpl at line 137

<tr class="bz_[% bug.bug_severity %] bz_[% bug.priority %] [%+ "bz_secure" IF
bug.isingroups %]">

where bz_secure is set whenever a bug is in a group which is always true when
you use the group system on product level. The rule for bz_secure should also
check if the parameter for using the product-group system is set to off.

Comment 1

[Dave Miller [:justdave]]

That wouldn't really work either, because I don't want it to create new groups
every time I create a new product (so I have that param off), but I still have
all my products locked down (most of them to the same group).  It does look kind
of silly if you have a different-than-default background in your templates...

Comment 2

[Andreas Otte]

So what could be the solution for this? This is a comment from buglist.css on
bz_secure:

/* Style secure bugs if the installation is not using bug groups.   
 * Installations that *are* using bug groups are likely to be using 
 * them for almost all bugs, in which case special styling is not   
 * informative and generally a nuisance.                            
 */                                                                 

Currently the first line in the comment is ignored it seems. 

Comment 3

[Dave Miller [:justdave]]

maybe we need a checkbox in the group editor...

"use the bz_secure class in buglists for bugs in this group"

That would work for me, since I could care less if the bug is in its product's
group, but it's be useful to have it pointed out when it's restricted visibility
to the engineering department. :)

Comment 4

[Bradley Baetz (:bbaetz)]

The other problem is that the definition of a 'secure' group is a great deal
larger in 2.17 than in 2.16, because of the rewrite.

Comment 5

[Joel Peshkin]

This is a general problem.  

To make sensible use of this type of highlighting when making real use of the
new groups system, I had to do some very site-specific hacks.  See bug 186093

The real question is..... how should this work?

Comment 6

[Dave Miller [:justdave]]

Joel: see comment 3, that's my suggestion. :)

Comment 7

[Andreas Otte]

I agree with Dave, it could be done this way. For now I have disabled bz_secure
at all in my installation.

Comment 8

[Gervase Markham [:gerv]]

Should this "work" at all? That is, should we not expect admins to style bugs
based on their groups themselves, according to their site-specific policies?

Gerv

Comment 9

[Joel Peshkin]

Using single groups as in comment 3 does not really cover it well because it
ignores inheritance.

I found that the way to get meaningfull answers is to use a (disabled)
pseudo-user and style according to the question.... can pesudo_user see this?

Unfortunately, that is a bit slow for long lists.

Comment 10

[Andreas Otte]

Currently bz_secure overwrites all other markings for blockers, enhancements,
etc. In an environment where every bug is in a group and bz_secure reacts on
that it makes only sense to deactivate it completely. So I would vote for a
single parameter that can switch off usage of bz_secure in buglists
independently from the group system.

Comment 11

[Christian Reis]

Being forced to tackle this finally in bug 252810.

Comment 12

[Joel Peshkin]

Actually, if makeproductgroups is enabled, all bugs are going to be secure by
default.  If we want to mimic the old behavior, we should skip bs_secure if
makeproductgroups is enabled.

Comment 13

[Dave Miller [:justdave]]

(In reply to comment #12)
> Actually, if makeproductgroups is enabled, all bugs are going to be secure by
> default.  If we want to mimic the old behavior, we should skip bs_secure if
> makeproductgroups is enabled.

Makes sense for 2.18, and short-term for the trunk.  Long term perhaps we should
try to get a UI on that color-coding scheme you mentioned you had on your site
for setting colors based on who could see the bug :)

Comment 14

[Christian Reis]

I believe this was fixed with the checkin to bug 252810, which styles secure
bugs with a padlock next to their IDs. Please reopen and maim me if it's still
an issue.

Comment 15

[Marc Schumann [:Wurblzap]]

I think what's left over might be related to bug 179274 and bug 255512.