171493 - make show_bug use Bug.pm and remove bug_form.pl

Status: RESOLVED FIXED

(Bugzilla :: Creating/Changing Bugs, defect, P2)

Description

[Bradley Baetz (:bbaetz)]

This is basically the first part of bug 158499 comment 6.

Basically, all the users oif bug_form.pl instead pass a Bug object to a
template. This involves several changes:

1) bug_form's var names weren't the same as Bug.pm's, so they had to be changed
2) lots of prepending of |bug.| in the template
3) separating the templates a bit, so that we can handle the 'show next bug' thing
4) removing unused/broken modification stuff from Bug.pm
5) moving some functionality from bug_form.pl into Bug.pm (mainly the 'can user
edit' and the 'available choices' stuff)
6) make quoteUrls/GetBugLink into filters, so that they can be used from the
template (and update existing callers, ie the page stuff)

The Bug.pm changes are semi-hacky, but its mainly just moving the code arround.
The hacky nature of it is why I left it where it is, rather than movinvg it to
Bugzilla. After we have a user module for users, then this will probably become
a lot nicer, so it can wait until then.

The buglist cookie stuff should go into some common routine, but I'm having
trouble working out where to put it - thoughts?

Comment 1

[Bradley Baetz (:bbaetz)]

Attachment: v0.9

Comment 2

[Bradley Baetz (:bbaetz)]

Attachment: v1

OK, try this. Its a semi-large patch, but most of it is removing stuff from
Bug.pm, and moving from bug_form.pl to Bug.pm. See y previous comment for
details on how this all works

Comment 3

[Gervase Markham [:gerv]]

Comment on attachment 101639 [details] [diff] [review]
v1

> Index: Bug.pm
> ===================================================================
> -  $self->{'assigned_to'} = &::DBID_to_name($self->{'assigned_to'});
> -  $self->{'reporter'} = &::DBID_to_name($self->{'reporter'});
> +  # XXX - delta_ts really should be seconds-since-the-epoch,
> +  # with all the formatting being in the template....

Please either fix all these XXX issues or remove the comment and file bugs
instead :-)

> +  $self->{'longdescs'} = &::GetComments($self->bug_id);

Can GetComments yet move into Bug.pm?

> +  $self->{'milestoneurl'} = $::milestoneurl{$self->product} ||
> +                            "notargetmilestone.html";

Urk. I cvs removed notargetmilestone.html a few days ago, because I couldn't
find any uses of it. Is this new, or did I miss one? Anyway, it's a silly thing
- we should just not hyperlink the words if one isn't defined.

> +  # XXX - preload

Huh? :-)

> +    # In the below, if the person hasn't logged in ($::userid == 0), then
> +    # we treat them as if they can do anything.  That's because we don't
> +    # know why they haven't logged in; it may just be because they don't
> +    # use cookies.  Display everything as if they have all the permissions
> +    # in the world; their permissions will get checked when they log in
> +    # and actually try to make the change.
> +    $self->{'user'}->{'canedit'} = $::userid == 0
> +                                   || $::userid == $self->{'reporter'}
> +                                   || $::userid == $self->{'qa_contact'}
> +                                   || $::userid == $self->{'assigned_to'}

The reporter doesn't get canedit. After careful consideration, we rewrote the
function which used to set these things (CheckCanChangeField in
process_bug.cgi) to DTRT. Please just leave these as whether the user is in the
group, and let CheckCanChangeField deal with the issues surrounding reporters,
assignees, QA contacts etc.

> +    $self->{'choices'} =
> +      {
> +       'product' => \@prodlist,
> +       'rep_platform' => \@::legal_platform,
> +       'priority' => \@::legal_priority,
> +       'bug_severity' => \@::legal_severity,
> +       'op_sys' => \@::legal_opsys,
> +       'bug_status' => \@::legal_bugs_status,
> +       'resolution' => \@::settable_resolution,
> +       'component_' => $::components{$self->product},
> +       'version' => $::versions{$self->product},
> +       'target_milestone' => $::target_milestone{$self->product},
> +      };
> +
> +    return $self->{'choices'};
> +}

Is the bug object logically the right place for this stuff? I don't think so.
Like I say below about user, even if you keep the code here, you should change
the template interface.

> Index: show_bug.cgi
> ===================================================================
> -print "Content-type: text/html\n\n";
> +my $bug = new Bug($::FORM{'id'}, $userid);
> +
> +die "Bug $::FORM{'id'} has error $bug->{'error'}" if $bug->error;

Why are we die-ing here? Surely we should be Throwing something. (Here and
elsewhere.)

> +$vars->{'bug'} = $bug;
> +
> +# Next bug in list (if there is one)
> +my @bug_list;
> +if ($::COOKIE{"BUGLIST"}) {
> +    @bug_list = split(/:/, $::COOKIE{"BUGLIST"});
> +}
> +$vars->{'bug_list'} = \@bug_list;
> +$vars->{'navigation_links'} = navigation_links(join(':',@bug_list));

This bit will have now rotted, because we removed the navigation_links() hack.
:-|

> Index: template/en/default/bug/edit.html.tmpl
> ===================================================================
> @@ -106,7 +90,7 @@
>        <td>
>          <label for="component" accesskey="m">
>            <select name="component" id="component">
> -            [% FOREACH x = component_ %]
> +            [% FOREACH x = bug.choices.component_ %]

If this is going to live in bug.choices, then it can be called "component" -
component is only a reserved word at the top level. Of course, renaming it may
actually complicate matters...

> -      <td>[% bug.assigned_to FILTER html %]</td>
> +      <td>[% bug.assigned_to_name FILTER html %]</td>

Just out of curiousity, why do we not have
bug.assigned_to.name, bug.assigned_to.email and bug.assigned_to.id (and the
same for reporter/QA contact)?

>    [% IF bug.bug_status == "UNCONFIRMED" && 
> -        user.canconfirm %]
> +        bug.user.canconfirm %]

Why is the user object now part of the bug object? They are logically separate
things.

<reads back> I see that for some reason you are getting information about the
user inside Bug.pm. If you have to do that for technical reasons (before, e.g.
the creation of Bugzilla::User) then you should still instantiate the template
with "user = bug.user", so that the interface inside it is more sane.

> -           (bug.resolution == "MOVED" && user.canmove) %]  
> +           (bug.resolution == "MOVED" && bug.user.canmove) %]  

<sigh> This should be a group, of course.

>  [% PROCESS bug/comments.html.tmpl 
> -   comments = bug.comments 
> +   comments = bug.longdescs 

Ick. I'd much rather we changed the interface of Bug.pm so that we called it
"comments" instead. Is that possible?

> Index: template/en/default/bug/show.html.tmpl
> ===================================================================

When we made edit.html.tmpl the filename for the top-level bug UI, it was
because we considered that perhaps later there would be a version which didn't
allow editing, and that would be show.html.tmpl. It would be better if you made
this file into edit.html.tmpl, and made the current contents of edit.html.tmpl
into e.g. form.html.tmpl, by analogy with the structure of the search page.

> +[% filtered_desc = bug.short_desc FILTER html %]
> +[% PROCESS global/header.html.tmpl 
> +  title = "Bug $bug.bug_id - $bug.short_desc"
> +  h1 = "Bugzilla Bug $bug.bug_id"
> +  h2 = filtered_desc
> +  h3 = "Last modified: $bug.calc_disp_date"

This is new. What's going on here?

Gerv

Comment 4

[Bradley Baetz (:bbaetz)]

Grrrrrr. I attached the wrong patch version... Anyway:

> Please either fix all these XXX issues or remove the comment and file bugs
> instead :-)

Some/most of these are 'things which should be done', more than anything else.
They generally can't be done now, because they depend on other changes which
arne't made yet. After this patch goes in, we need to convert
{long_list,xml}.cgi, and then bits of process_bug, before a lot of these
cleanups can be done. I guess I could file a 'clean up XXX comment stuff',
but... None of these are correctness issues, just style/efficiency.

> Can GetComments yet move into Bug.pm?

No - its used by process_bug (for midairs), and longlist. I'll move the
GetComments call into a longdescs sub, though

> Urk. I cvs removed notargetmilestone.html a few days ago, because I couldn't
> find any uses of it. Is this new, or did I miss one? Anyway, it's a silly thing
> - we should just not hyperlink the words if one isn't defined.

You missed it - grep for 'notargetmilesone', and it comes up in bug_form.pl.
I'll make that change, though

> > +  # XXX - preload

> Huh? :-)

Because of the way I've split this stuff into subs, we can avoid loading
information which isn't needed until its asked for. However, that requires the
locking to be revisited a bit, which is why I haven't done this now. I'll tidy
up the comment a bit.

> > +    $self->{'user'}->{'canedit'} = $::userid == 0
> > +                                   || $::userid == $self->{'reporter'}
> > +                                   || $::userid == $self->{'qa_contact'}
> > +                                   || $::userid == $self->{'assigned_to'}
>
> The reporter doesn't get canedit. After careful consideration, we rewrote the
> function which used to set these things (CheckCanChangeField in
> process_bug.cgi) to DTRT. Please just leave these as whether the user is in the
> group, and let CheckCanChangeField deal with the issues surrounding reporters,
> assignees, QA contacts etc.

This bit isn't to do with bug changes (Bug.pm is still readonly at this stage),
only the UI. I just copied this from bug_form.pl, and it looks like its wrong
there, too... File a new bug :)

> [choices in bug object]

Yes, this is correct. The reason is that the set of available choices depends on
the bug (Actually, on the product, but I don't think we need a 'product' option
at this stage) - IOW its a list of 'what can this bug value be set to' ? When
Bug.pm becomes writable, the sanity checks will bascially involve checking that
for every submitted form element with an entry in choices, that form element is
in there.

>> +die "Bug $::FORM{'id'} has error $bug->{'error'}" if $bug->error;

>Why are we die-ing here? Surely we should be Throwing something.

Nope - we checked for existance already by the time we got here. This is an
internal sanity check, again moved from bug_form.pl. Tidying that up is on the
agenda, but it really can't be done easily until all the bug users use Bug.pm

>> +$vars->{'navigation_links'} = navigation_links(join(':',@bug_list));
>This bit will have now rotted, because we removed the navigation_links() hack.
>:-|

Yeah, well, thats what I get for uploading the wrong version of the patch :) As
I mentioend in that other bug, that patch makes this one easier.

>> +            [% FOREACH x = bug.choices.component_ %]
>If this is going to live in bug.choices, then it can be called "component" -
>component is only a reserved word at the top level.

Ah, didn't know that. Will do.

> Of course, renaming it may actually complicate matters...

Such as?

> Just out of curiousity, why do we not have
> bug.assigned_to.name, bug.assigned_to.email and bug.assigned_to.id (and the
> same for reporter/QA contact)?

Because we don't have a User.pm object yet. I'm not sure what the interface to
that will end up looking like, so theres no advantage in trying to make this
code 'drop in replacable' with that new code, or some such thing.

> Why is the user object now part of the bug object? They are logically separate
> things.

Its not part of hte bug object. bug.user is a hash for 'interactions the user
can do to the bug'. Stuff like the 'what ui elements are editable' are a
function of the bug, so they belong on the bug object, but they also depend on
the user. I'll take better names, but I don't think one is needed.

The |user| element will be about the user ittself - id/groups/etc, and the
bug.user thing will then probably become bug.whatCanUserDo(user).whatever, or
something.

> Ick. I'd much rather we changed the interface of Bug.pm so that we called it
> "comments" instead. Is that possible?

Well, we could, but these names are based on the db schema deliberatly.

> When we made edit.html.tmpl the filename for the top-level bug UI, it was
> because we considered that perhaps later there would be a version which didn't
> allow editing, and that would be show.html.tmpl. It would be better if you made
> this file into edit.html.tmpl, and made the current contents of edit.html.tmpl
> into e.g. form.html.tmpl, by analogy with the structure of the search page.

Hmmm. The medium term goal (after this bug) is to have show.xml.tmpl, and
show-longlist.html.tmpl, all powered by this same script, using formats. I was
thinking of having show-longlist jsut take a list of bugs, instead of one bug,
in which case I guess that could become the non-editable thing, which a
one-element list.

I guess I could use show-editable.html.tmpl, and hard code in a format for the
no-format case. Hmm... Would that work for you?

>> [ ... ]
>> +  h2 = filtered_desc
>> +  h3 = "Last modified: $bug.calc_disp_date"
> This is new. What's going on here?

No its not - its just moved arround into the other template.

Anyway, I'll fix these issues up, and attach a new patch

Comment 5

[Bradley Baetz (:bbaetz)]

> I guess I could use show-editable.html.tmpl, and hard code in a format for the
> no-format case

Actually, I've changed my mind. The default result of showing a bug is the
editable format. IF you want a read-only view, then use show-multiple.html.tmpl,
with one entyr in the list, and s/multiple/list/, or something.

Comment 6

[Bradley Baetz (:bbaetz)]

Attachment: third go

Gerv's issues fixed, except for that template naming stuff, which I think
should be as-is.

Comment 7

[Gervase Markham [:gerv]]

>> Please either fix all these XXX issues or remove the comment and file bugs
>> instead :-)
> 
> Some/most of these are 'things which should be done', more than anything else.
> They generally can't be done now, because they depend on other changes which
> arne't made yet. After this patch goes in, we need to convert
> {long_list,xml}.cgi, and then bits of process_bug, before a lot of these
> cleanups can be done. I guess I could file a 'clean up XXX comment stuff',
> but... None of these are correctness issues, just style/efficiency.

Even so, I'd much rather have a bug in b.m.o. which says "Make foo more
efficient in Bug.pm" than an XXX comment to that effect.
 
> Because of the way I've split this stuff into subs, we can avoid loading
> information which isn't needed until its asked for. However, that requires the
> locking to be revisited a bit, which is why I haven't done this now. I'll tidy
> up the comment a bit.

Or file a bug, even :-P
 
>> The reporter doesn't get canedit. After careful consideration, we rewrote the
>> function which used to set these things (CheckCanChangeField in
>> process_bug.cgi) to DTRT. Please just leave these as whether the user is in the
>> group, and let CheckCanChangeField deal with the issues surrounding reporters,
>> assignees, QA contacts etc.
> 
> This bit isn't to do with bug changes (Bug.pm is still readonly at this stage),
> only the UI. I just copied this from bug_form.pl, and it looks like its wrong
> there, too... File a new bug :)

What are the ramifications of this and CheckCanChangeField not matching up?
 
>> [choices in bug object]
> 
> Yes, this is correct. The reason is that the set of available choices depends on
> the bug (Actually, on the product, but I don't think we need a 'product' option
> at this stage) - IOW its a list of 'what can this bug value be set to' ? When
> Bug.pm becomes writable, the sanity checks will bascially involve checking that
> for every submitted form element with an entry in choices, that form element is
> in there.

But this means this info will be duplicated across bug objects in the same
product. Is that a problem?
 
>>> +die "Bug $::FORM{'id'} has error $bug->{'error'}" if $bug->error;
> 
>>Why are we die-ing here? Surely we should be Throwing something.
> 
> Nope - we checked for existance already by the time we got here. This is an
> internal sanity check, again moved from bug_form.pl. Tidying that up is on the
> agenda, but it really can't be done easily until all the bug users use Bug.pm

Let me put it another way - what technical reason prevents us from using the
error-reporting mechanism all the rest of our code uses? "We'll never hit this
condition" is not a valid reason :-) I notice you've done it in one place - great. 
 
>> Of course, renaming it may actually complicate matters...
> 
> Such as?

I don't know - perhaps if it was matching a component_ elsewhere. Never mind :-)
 
>> Just out of curiousity, why do we not have
>> bug.assigned_to.name, bug.assigned_to.email and bug.assigned_to.id (and the
>> same for reporter/QA contact)?
> 
> Because we don't have a User.pm object yet. I'm not sure what the interface to
> that will end up looking like, so theres no advantage in trying to make this
> code 'drop in replacable' with that new code, or some such thing.

But there is an advantage in making the temporary interface nicer, if it's not
more effort (which it isn't, really.)
 
>> Why is the user object now part of the bug object? They are logically separate
>> things.
> 
> Its not part of hte bug object. bug.user is a hash for 'interactions the user
> can do to the bug'. Stuff like the 'what ui elements are editable' are a
> function of the bug, so they belong on the bug object, but they also depend on
> the user. I'll take better names, but I don't think one is needed.
> 
> The |user| element will be about the user ittself - id/groups/etc, and the
> bug.user thing will then probably become bug.whatCanUserDo(user).whatever, or
> something.

OK, I'll buy that for now. :-)

> Index: Bug.pm
> ===================================================================

> +        # For product groups, we only want to display the checkbox if either

This comment needs adjusting for sanity.

> Index: post_bug.cgi
> ===================================================================
> +# Set up the <link> elements for forward/back/etc, if we have that link

And this one.

> +ThrowCodeError("bug_error") if $bug->error;

Excellent :-)

> Index: template/en/default/bug/show.html.tmpl
> ===================================================================
> +[% PROCESS global/header.html.tmpl 
> +  title = "Bug $bug.bug_id - $bug.short_desc"
> +  h1 = "Bugzilla Bug $bug.bug_id"
> +  h2 = filtered_desc
> +  h3 = "Last modified: $bug.calc_disp_date"

You say this isn't new, but it isn't in the current b.m.o. interface...

> +  header_html = navigation_links

Again, this is no longer right. :-)

> Index: template/en/default/bug/process/next.html.tmpl
> ===================================================================
>  [%# INTERFACE:
> -  # next_id : number; the ID of the next bug in the user's bug list.
> +  # bug : Bug.pm object; the next bug to show
>    #%]

Nit: I'd adopt the terminology "Bug object" (and "User object" etc.), as opposed
to "Bug.pm module". IYSWIM.

Remember that at least one page.cgi page uses quoteUrls, and will need updating
to use the FILTER form.

Re: template names. OK. Either is good enough, so I won't fight about it.

Gerv

Comment 8

[Bradley Baetz (:bbaetz)]

> What are the ramifications of this and CheckCanChangeField not matching up?

The user sees things which look changable, but in fact are not, and if they try
to change them they get an error message

>><choices stuff>
>But this means this info will be duplicated across bug objects in the same
>product. Is that a problem?

Well, it cna be lazily loaded, remember, and we only support editing one bug at
once this way, so....

I don't think that this is an issue - we're not copying the array, just a set of
references. When we end up pulling these out of the db, then we can lok at some
sort of local cache.

Comment 9

[Bradley Baetz (:bbaetz)]

Attachment: v4

OK, gerv's nits fixed

Comment 10

[Bradley Baetz (:bbaetz)]

Attachment: v4.1

OK, so I need to change then diff, not diff then change....

This just fixes the two |die| things I missed

Comment 11

[Gervase Markham [:gerv]]

Comment on attachment 102651 [details] [diff] [review]
v4.1

r=gerv. I'd be happier if this got a second review, though, as it's a bit of an
upheaval.

Gerv

Comment 12

[Bradley Baetz (:bbaetz)]

Attachment: fix bitrot from EAR patch

Comment 13

[Joel Peshkin]

Comment on attachment 102710 [details] [diff] [review]
fix bitrot from EAR patch

1) Fix function calls in Bug.pm --- SendSQL, FetchSQLData, UserInGroup

2) Fix indent levels (nit) in Bug.pm

3) post_bug.cgi returns... file error - formattimeunit: not found

I'll retest once this bunch is fixed.

Comment 14

[Joel Peshkin]

Incidentally, the other error seems to come from the absence of 
[% PROCESS "bug/time.html.tmpl" %]
before
[% PROCESS "bug/edit.html.tmpl" %]
in bug/process/next.html.tmpl" 

Comment 15

[Bradley Baetz (:bbaetz)]

Attachment: v6

Comment 16

[Bradley Baetz (:bbaetz)]

Comment on attachment 106651 [details] [diff] [review]
v6

There will be a bit of breakage from the group patch, but that should be
trivial toresolve.

Joel, can you test this with time tracking? I moved the time.html.tmpl load
into edit.html.tpl - if it needs it, it should be responsible for loading the
BLOCKs

I also changed code to use User.pm for email/name lookup

Apart from that, this si ready for review

Comment 17

[Joel Peshkin]

Let's hold this until 147275 lands.  It will conflict all over the place.

Comment 18

[Bradley Baetz (:bbaetz)]

joel: Sure, but you can basically review it anyway, and then redo it quickly
afterwards - the only chnage will be  afew lines in bug_form.pl which I'll jut
copy over.

I'm particularly interested in teh time tracking stuff.

Comment 19

[Bradley Baetz (:bbaetz)]

Attachment: update from groups rewrite (v7)

OK, try this. The patch is a bit large, but los of this is just moving from
bug_form.pl and Bug.pm

Comment 20

[Bradley Baetz (:bbaetz)]

Attachment: real v7

Oops, wrong version...

Comment 21

[Bradley Baetz (:bbaetz)]

Comment on attachment 107321 [details] [diff] [review]
real v7

This si simpler than it looks. You probably want to review bug_form.pl and
Bug.pm side by side to see the code movement.

Ignore the Bugzilla/CGI.pm $| change - that wasn't meant ot be there

Comment 22

[Joel Peshkin]

Comment on attachment 107321 [details] [diff] [review]
real v7


SQL errors when timetracking is enabled.

SELECT SUM(work_time) FROM longdescs WHERE
longdescs.bug_id=Bug=HASH(0x85a9464)->bug_id:

Comment 23

[Bradley Baetz (:bbaetz)]

Attachment: v8

OK, fixed that, and also moved all the $self->foo calls to $self->{foo} - hash
lookups are cheaper than function calls.

Comment 24

[Bradley Baetz (:bbaetz)]

Comment on attachment 107342 [details] [diff] [review]
v8

dave, can you do an r2 for this, please?

Comment 25

[Joel Peshkin]

Comment on attachment 107342 [details] [diff] [review]
v8

r=joel
(This does need doing, but I suspect a lot of patches in the air will break)

Comment 26

[Gervase Markham [:gerv]]

(After a quick look, this seems OK to me.)

Gerv

Comment 27

[Bradley Baetz (:bbaetz)]

Attachment: v9

fixed bitrot

Comment 28

[Bradley Baetz (:bbaetz)]

Comment on attachment 107669 [details] [diff] [review]
v9

joel, can you please re-r= this? just minor bitrot-fixing changes

Comment 29

[Bradley Baetz (:bbaetz)]

Checked in.

Checking in Bug.pm;
/cvsroot/mozilla/webtools/bugzilla/Bug.pm,v  <--  Bug.pm
new revision: 1.23; previous revision: 1.22
done
Removing bug_form.pl;
/cvsroot/mozilla/webtools/bugzilla/bug_form.pl,v  <--  bug_form.pl
new revision: delete; previous revision: 1.113
done
Checking in checksetup.pl;
/cvsroot/mozilla/webtools/bugzilla/checksetup.pl,v  <--  checksetup.pl
new revision: 1.207; previous revision: 1.206
done
Checking in globals.pl;
/cvsroot/mozilla/webtools/bugzilla/globals.pl,v  <--  globals.pl
new revision: 1.222; previous revision: 1.221
done
Checking in post_bug.cgi;
/cvsroot/mozilla/webtools/bugzilla/post_bug.cgi,v  <--  post_bug.cgi
new revision: 1.76; previous revision: 1.75
done
Checking in process_bug.cgi;
/cvsroot/mozilla/webtools/bugzilla/process_bug.cgi,v  <--  process_bug.cgi
new revision: 1.172; previous revision: 1.171
done
Checking in show_bug.cgi;
/cvsroot/mozilla/webtools/bugzilla/show_bug.cgi,v  <--  show_bug.cgi
new revision: 1.20; previous revision: 1.19
done
Checking in Bugzilla/User.pm;
/cvsroot/mozilla/webtools/bugzilla/Bugzilla/User.pm,v  <--  User.pm
new revision: 1.13; previous revision: 1.12
done
Checking in t/004template.t;
/cvsroot/mozilla/webtools/bugzilla/t/004template.t,v  <--  004template.t
new revision: 1.22; previous revision: 1.21
done
Checking in template/en/default/bug/comments.html.tmpl;
/cvsroot/mozilla/webtools/bugzilla/template/en/default/bug/comments.html.tmpl,v
 <--  comments.html.tmpl
new revision: 1.7; previous revision: 1.6
done
Checking in template/en/default/bug/edit.html.tmpl;
/cvsroot/mozilla/webtools/bugzilla/template/en/default/bug/edit.html.tmpl,v  <--
 edit.html.tmpl
new revision: 1.29; previous revision: 1.28
done
RCS file:
/cvsroot/mozilla/webtools/bugzilla/template/en/default/bug/show.html.tmpl,v
done
Checking in template/en/default/bug/show.html.tmpl;
/cvsroot/mozilla/webtools/bugzilla/template/en/default/bug/show.html.tmpl,v  <--
 show.html.tmpl
initial revision: 1.1
done
Checking in template/en/default/bug/create/created.html.tmpl;
/cvsroot/mozilla/webtools/bugzilla/template/en/default/bug/create/created.html.tmpl,v
 <--  created.html.tmpl
new revision: 1.5; previous revision: 1.4
done
Checking in template/en/default/bug/process/next.html.tmpl;
/cvsroot/mozilla/webtools/bugzilla/template/en/default/bug/process/next.html.tmpl,v
 <--  next.html.tmpl
new revision: 1.2; previous revision: 1.1
done
Checking in template/en/default/global/code-error.html.tmpl;
/cvsroot/mozilla/webtools/bugzilla/template/en/default/global/code-error.html.tmpl,v
 <--  code-error.html.tmpl
new revision: 1.23; previous revision: 1.22
done
Checking in template/en/default/global/site-navigation.html.tmpl;
/cvsroot/mozilla/webtools/bugzilla/template/en/default/global/site-navigation.html.tmpl,v
 <--  site-navigation.html.tmpl
new revision: 1.4; previous revision: 1.3
done
Checking in template/en/default/pages/linked.html.tmpl;
/cvsroot/mozilla/webtools/bugzilla/template/en/default/pages/linked.html.tmpl,v
 <--  linked.html.tmpl
new revision: 1.3; previous revision: 1.2
done

Comment 30

[Bradley Baetz (:bbaetz)]

*** Bug 156820 has been marked as a duplicate of this bug. ***

Comment 31

[victory <[e-mail]>]

Attachment: docs patch about 'Bugzilla Database Tables' section, for 2.18

Comment 32

[victory <[e-mail]>]

Attachment: docs patch about 'Bugzilla Database Tables' section, for 2.18 v2

it seems this bug also changed 'groups'..

Comment 33

[timeless]

Comment on attachment 214044 [details] [diff] [review]
docs patch about 'Bugzilla Database Tables' section, for 2.18 v2

>+group_control_map:  This table stores the relationship of groups to
>+products.

didn't i just review that elsewhere?

>+groups:  This table stores group name, description, last changed time,
>+userregexp, and whether associated with specific product, whether bugs
>+can be added to the group.

'and' should be betweeen the list and the last item, not between the list and the second to last item.

userregexp, ||whether _it is_ associated with _a_ specific product, _and_ whether bugs can be added to the group.