It is rather funny. I select and view a bug. The form seems to permit me to make changes. I am denied permission after I submit. May be I feel this way as I am new to Bugzilla

That is correct. If you want to change a bug which was not filed by you, then you need permission in bugzilla to do so. If you were logged in when you looked at the bug, then the options on the form would not have been shown.

We should indicate on the form near the commit button "You are not currently logged in, some of these options may not be available to you based on your privileges when you log in"

Or make the controls unavailable in the UI, which is nicer.

I've often wondered about that, and various people usually shoot it down. It should probably just show the basic data without any type of form and force you to log in to be able to change anything. Being able to change a bug and get prompted for your ID when you hit Commit is probably just a convenience that people will need to learn to live without...

Some discussion about disabling bits of the form if people don't have rights to change them is on bug#95923 -- my vote would be to disable stuff if the user can't change it.

What to offer in Bugzilla when you are not logged in is really the perpetual question haunting the project. Sometimes we offer (eg fields), sometimes we don't (eg admin functions). It's just too hairy a question to answer, so don't mind me if I proceed to go shove my head in the sand on the matter.

Just to note my opinion here as well: I'd go for the approach presented by Dave in comment 4: show the form only if you're (reasonably) certain that the user can actually use it. That more fair that way, and it's not a big job to log in before making the changes. That would make the show_bug UI far less intimidating for newbies, thus encouraging use of Bugzilla.

These unloved bugs have been sitting untouched since June 2002 or longer. If nobody does anything else to them, they certainly won't make 2.18 Retargetting to 2.20. If you really plan to push them right now, you might pull them back in.

This bug has not been touched by its owner in over six months, even though it is targeted to 2.20, for which the freeze is 10 days away. Unsetting the target milestone, on the assumption that nobody is actually working on it or has any plans to soon. If you are the owner, and you plan to work on the bug, please give it a real target milestone. If you are the owner, and you do *not* plan to work on it, please reassign it to nobody@bugzilla.org or a .bugs component owner. If you are *anybody*, and you get this comment, and *you* plan to work on the bug, please reassign it to yourself if you have the ability.

We could use the new UI from bug 219555, see the attached screenshot there, when the user is not logged in. All information the user may want to know is displayed, including flags and attachments.

Logged out users get the new and improved Format For Printing page with a small login form. Above the form there is some text saying they must login/create an acocunt if they would want to cc or make changes. Changes the logged out procedure from: 1. Logged out user sees show_bug.cgi 2. Makes changes 3. Click submit 4. Logs in 5. If all changes passes permissions tests, receives bugmail To: 1. Logged out user sees simplified show_bug.cgi 2. Logs in 3. Makes changes (show_bug.cgi shows exact permissions) 4. Click submit 5. Receives bugmail So benefit is: * Random people visiting a bug see a simplified bug page * Logged out users still see their correct permissions

Comment on attachment 229509 [details] [diff] [review] Patch v1 >Index: template/en/default/bug/show-multiple.html.tmpl >+ [% h1 = "$terms.Bug&nbsp;$bug.bug_id" %] Must be $bugs.0.bug_id >+ [% IF show_login_form && user.authorizer.can_login %] >+ <tr> >+ <td colspan="4" class="login"> >+ To add yourself to the cc-list or change this bug, please login below >+ [% IF Param('createemailregexp') && user.authorizer.user_can_create_account %] >+ or <a href="createaccount.cgi">create an account</a> >+ [% END %]. >+ [% PROCESS "account/auth/login-small.html.tmpl" >+ loginfields = { id => bug.bug_id } %] >+ </td> >+ </tr> >+ [% END %] Per discussion with myk on IRC, we agreed that a better design was to have the login form in the header, in place of the current "Log In" link. Except from that, your patch works fine.

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

Requesting blocking for 3.0 as part of our UI rework.

Note: - I do not PROCESS knob.html.tmpl because of the Commit button - The Bugzilla/Bug.pm changes prevents knob.html.tmpl from showing every option (if that template was used). - How I show the flags is from the 'format for printing' page (show-multiple.html.tmpl)

Comment on attachment 243131 [details] [diff] [review] Patch v2 >Index: template/en/default/bug/edit.html.tmpl >+ [% FOREACH type = bug.flag_types %] >+ [% FOREACH flag = type.flags %] >+ [% flag.setter.nick FILTER html %]: >+ [%+ flag.type.name FILTER html FILTER no_break %][% flag.status %] >+ [%+ IF flag.status == "?" && flag.requestee %] >+ ([% flag.requestee.nick FILTER html %]) >+ [% END %]<br> >+ [% END %] >+ [% END %] Nits: 1) If there is a requestee, then the flag is set to "?", so your test could be [% IF flag.requestee %] 2) I don't like parens around the requestee. I know there are there when the flags are editable, but this really looks bad here. Please remove them. 3) You can write 'type.name' instead of 'flag.type.name'. This would be more readable. r=LpSolit with these nits fixed. They can be fixed on checkin.

<LpSolit> hum, bkor: forget my nit about parens <LpSolit> bkor: I just realized there are in the attachment table too <LpSolit> bkor: so let's be consistent and keep them (at least for now) Rest was changed. Not attaching patch as these changes are so trivial (have tested them of course). Checking in Bugzilla/Bug.pm; /cvsroot/mozilla/webtools/bugzilla/Bugzilla/Bug.pm,v <-- Bug.pm new revision: 1.161; previous revision: 1.160 done Checking in template/en/default/filterexceptions.pl; /cvsroot/mozilla/webtools/bugzilla/template/en/default/filterexceptions.pl,v <-- filterexceptions.pl new revision: 1.87; previous revision: 1.86 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.91; previous revision: 1.90 done