Closed
Bug 171493
Opened 22 years ago
Closed 22 years ago
make show_bug use Bug.pm and remove bug_form.pl
Categories
(Bugzilla :: Creating/Changing Bugs, defect, P2)
Tracking
()
RESOLVED
FIXED
Bugzilla 2.18
People
(Reporter: bbaetz, Assigned: bbaetz)
References
Details
Attachments
(1 file, 12 obsolete files)
(deleted),
patch
|
justdave
:
review+
bugreport
:
review+
|
Details | Diff | Splinter Review |
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?
Assignee | ||
Comment 1•22 years ago
|
||
Assignee | ||
Updated•22 years ago
|
Status: NEW → ASSIGNED
Priority: -- → P2
Target Milestone: --- → Bugzilla 2.18
Assignee | ||
Comment 2•22 years ago
|
||
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
Assignee | ||
Updated•22 years ago
|
Attachment #101040 -
Attachment is obsolete: true
Comment 3•22 years ago
|
||
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
Attachment #101639 -
Flags: review-
Assignee | ||
Comment 4•22 years ago
|
||
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
Assignee | ||
Comment 5•22 years ago
|
||
> 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.
Assignee | ||
Comment 6•22 years ago
|
||
Gerv's issues fixed, except for that template naming stuff, which I think
should be as-is.
Attachment #101639 -
Attachment is obsolete: true
Comment 7•22 years ago
|
||
>> 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
Assignee | ||
Comment 8•22 years ago
|
||
> 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.
Assignee | ||
Comment 9•22 years ago
|
||
OK, gerv's nits fixed
Attachment #101975 -
Attachment is obsolete: true
Assignee | ||
Comment 10•22 years ago
|
||
OK, so I need to change then diff, not diff then change....
This just fixes the two |die| things I missed
Attachment #102650 -
Attachment is obsolete: true
Comment 11•22 years ago
|
||
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
Attachment #102651 -
Flags: review+
Assignee | ||
Comment 12•22 years ago
|
||
Attachment #102651 -
Attachment is obsolete: true
Comment 13•22 years ago
|
||
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.
Attachment #102710 -
Flags: review-
Comment 14•22 years ago
|
||
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"
Assignee | ||
Comment 15•22 years ago
|
||
Attachment #102710 -
Attachment is obsolete: true
Assignee | ||
Comment 16•22 years ago
|
||
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
Attachment #106651 -
Flags: review?(bugreport)
Comment 17•22 years ago
|
||
Let's hold this until 147275 lands. It will conflict all over the place.
Depends on: 147275
Assignee | ||
Comment 18•22 years ago
|
||
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.
Assignee | ||
Updated•22 years ago
|
Assignee | ||
Comment 19•22 years ago
|
||
OK, try this. The patch is a bit large, but los of this is just moving from
bug_form.pl and Bug.pm
Assignee | ||
Updated•22 years ago
|
Attachment #106651 -
Attachment is obsolete: true
Assignee | ||
Comment 20•22 years ago
|
||
Oops, wrong version...
Attachment #107320 -
Attachment is obsolete: true
Assignee | ||
Updated•22 years ago
|
Attachment #106651 -
Flags: review?(bugreport)
Assignee | ||
Comment 21•22 years ago
|
||
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
Attachment #107321 -
Flags: review?(bugreport)
Comment 22•22 years ago
|
||
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:
Assignee | ||
Comment 23•22 years ago
|
||
OK, fixed that, and also moved all the $self->foo calls to $self->{foo} - hash
lookups are cheaper than function calls.
Attachment #107321 -
Attachment is obsolete: true
Assignee | ||
Updated•22 years ago
|
Attachment #107321 -
Flags: review?(bugreport)
Assignee | ||
Updated•22 years ago
|
Attachment #107342 -
Flags: review?(bugreport)
Assignee | ||
Comment 24•22 years ago
|
||
Comment on attachment 107342 [details] [diff] [review]
v8
dave, can you do an r2 for this, please?
Attachment #107342 -
Flags: review?(justdave)
Comment 25•22 years ago
|
||
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)
Attachment #107342 -
Flags: review?(bugreport) → review+
Comment 26•22 years ago
|
||
(After a quick look, this seems OK to me.)
Gerv
Assignee | ||
Updated•22 years ago
|
Attachment #107342 -
Flags: review?(justdave)
Assignee | ||
Updated•22 years ago
|
Attachment #107669 -
Flags: review?(justdave)
Assignee | ||
Comment 28•22 years ago
|
||
Comment on attachment 107669 [details] [diff] [review]
v9
joel, can you please re-r= this? just minor bitrot-fixing changes
Attachment #107669 -
Flags: review?(bugreport)
Updated•22 years ago
|
Attachment #107669 -
Flags: review?(bugreport) → review+
Updated•22 years ago
|
Attachment #107669 -
Flags: review?(justdave)
Updated•22 years ago
|
Flags: approval+
Assignee | ||
Comment 29•22 years ago
|
||
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
Status: ASSIGNED → RESOLVED
Closed: 22 years ago
Resolution: --- → FIXED
Assignee | ||
Comment 30•22 years ago
|
||
*** Bug 156820 has been marked as a duplicate of this bug. ***
Comment 31•19 years ago
|
||
Attachment #214026 -
Flags: review?(documentation)
Comment 32•19 years ago
|
||
it seems this bug also changed 'groups'..
Attachment #214026 -
Attachment is obsolete: true
Attachment #214044 -
Flags: review?(documentation)
Attachment #214026 -
Flags: review?(documentation)
Comment 33•19 years ago
|
||
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.
Attachment #214044 -
Flags: review?(documentation) → review-
Updated•18 years ago
|
Attachment #214044 -
Attachment is obsolete: true
Updated•12 years ago
|
QA Contact: matty_is_a_geek → default-qa
You need to log in
before you can comment on or make changes to this bug.
Description
•