Closed Bug 322960 Opened 18 years ago Closed 18 years ago

Release Notes for Bugzilla 2.22rc1

Categories

(Bugzilla :: Documentation, defect)

2.21
defect
Not set
blocker

Tracking

()

RESOLVED FIXED
Bugzilla 2.22

People

(Reporter: mkanat, Assigned: mkanat)

References

()

Details

Attachments

(1 file, 6 obsolete files)

We will need Release Notes for 2.22rc1. This is a fairly significant task.

If anybody else in the world would like to do this besides me, please, *please* feel free.

Look at the 2.20 Release Notes for an example.
please don't steal my QA guys for this job. They have enough testing to do. ;)
From karl (thanks for the memo, RSZ!):

User impersonation (think of the su/sudo command on Unix) allows you
 to view pages and perform actions as if you are logged in as someone else,
 without having to know their password.
Access to this feature is controlled by membership in the "bz_sudo" group,
 and users in the "bz_sudo_protect" group can be protected from impersonation.
OK, I'm working on this now.
Assignee: documentation → mkanat
Status: NEW → ASSIGNED
Attached patch Work In Progress (obsolete) — Splinter Review
Attached patch v1 (obsolete) — Splinter Review
OK, here are the Release Notes! You'll notice that in addition to the standard updates, I made a few changes to the "How to Upgrade" instructions to make some things clearer.

I don't have the 2.22rc1 Security Advisory in here, because we don't usually relnote the sec advisories until a release is actually finalized. However, I did note the Session ID fix, since that's an important security fix, but there won't be an advisory (since everybody already knew about it).
Attachment #211456 - Attachment is obsolete: true
Attachment #211657 - Flags: review?(LpSolit)
Attached patch Actual v1 (obsolete) — Splinter Review
OK, this is the actual patch. :-)
Attachment #211657 - Attachment is obsolete: true
Attachment #211658 - Flags: review?(LpSolit)
Attachment #211657 - Flags: review?(LpSolit)
Attached patch v2 (obsolete) — Splinter Review
LpSolit noticed that I had accidentally removed some stuff from the 2.20 Release Notes.

Also, I noticed that I forgot to relnote part of bug 119524 that I had intended to relnote.
Attachment #211658 - Attachment is obsolete: true
Attachment #211659 - Flags: review?(LpSolit)
Attachment #211658 - Flags: review?(LpSolit)
Attached patch v3 (obsolete) — Splinter Review
OK, a few other updates that I noticed as I was going through the "relnote" bugs to remove the "relnote" keyword from them (since they had been relnote'd).
Attachment #211659 - Attachment is obsolete: true
Attachment #211662 - Flags: review?(LpSolit)
Attachment #211659 - Flags: review?(LpSolit)
Attached patch v3.1 (obsolete) — Splinter Review
I had the error in there again where I removed stuff from 2.20.
Attachment #211662 - Attachment is obsolete: true
Attachment #211666 - Flags: review?(LpSolit)
Attachment #211662 - Flags: review?(LpSolit)
Comment on attachment 211666 [details] [diff] [review]
v3.1

>+All Pages Use Templates
>+-----------------------
>+Every single .cgi file in Bugzilla now uses templates, including all of

This is not exactly true. At least sanitycheck.cgi and reports.cgi (old charts) aren't templatized. And reports.cgi will never be.


>+One Codebase, Multiple Databases

Someone else should review this part. I never used this feature.


>+However, they cannot "become" any user in the "bz_sudo_protect" group.
>+This group automatically includes everybody in the "admin" group.

Also automatically included are users of the bz_sudoers group themselves.


>+Adding Individual Bugs to Saved Searches
>+----------------------------------------
>+Users now have the option in their footer of adding an individual bug 
>+number to any particular Saved Search.

Note that adding bugs to a saved search which is not a list of bug IDs will overwrite the current saved search, i.e. the saved search is lost.


>+However, users in the "admin" group can see all Products in 
>+editcomponents.cgi, even if they wouldn't normally have access to them.

Wrong! You can only see products you are allowed to see, even with admin privs. Moreover, this restriction also affects editversions.cgi, editmilestones.cgi and editproducts.cgi itself.


>+- Users can now actually see the descriptions of flags that you enter
>+  in editflagtypes.cgi.

You should explain how. A tooltip is displayed when pointing on a flag on show_bug.cgi.


>+- $::template and $::vars are gone from globals.pl.

You should also mention $::userid which is now replaced by Bugzilla->user->id.



You should also mention:
- the new 'strict_isolation' parameter which permits you to be very restrictive on who can access a bug or a product (bug 309681).

- You can now attach URLs instead of files (bug 149504).

- You can now change the assignee and QA contact on multiple bugs at once even when those bugs are in different products (bug 109339)
Attachment #211666 - Flags: review?(LpSolit) → review-
Comment on attachment 211666 [details] [diff] [review]
v3.1

In addition to what Frédéric mentioned...

>+One Codebase, Multiple Databases
>+Bug Import and Moving Improvements
>+Adding Individual Bugs to Saved Searches

I don't know much about any of these.

>+  Mail::Mailer v1.67     (changed from 2.20)

Bug 325579 and bugzilla-support@ seem to indicate a broken SMTP sub-module of MailTools-1.73, which is the most current version. Versions 1.68 through 1.72 are considered doubtful. Maybe we should add a note about this.

>+All Pages Use Templates

I'd drop this section entirely for Frédéric's reasons.

>+If you are upgrading and you want to use UTF-8, just turn on the "useutf8"

The parameter is called "utf8".

>+database, you're safe to turn on the "useutf8" parameter, definitely.)

Same here.

>+This group automatically includes everybody in the "admin" group.

I'd rather have "by default" in place of "automatically" here. In my mind, "automatically" implies it being hard-wired, which it isn't.

Side note -- maybe this is a bug in itself: if we don't want anybody to gain admin privs using sudo, then maybe we should put editusers into sudo_protect as well?

>+- Users can now actually see the descriptions of flags that you enter
>+  in editflagtypes.cgi.

I'd like to stress what Frédéric said. Tooltips aren't too obvious or friendly :)
Comment on attachment 211666 [details] [diff] [review]
v3.1

>+All Pages Use Templates

As others have pointed out, not quite true.

>+One Codebase, Multiple Databases
>+--------------------------------
>+There is now limited support for having multiple projects use the
>+same Bugzilla codebase, but all have separate databases.
>+
>+The different projects can have their own templates and their own
>+bug database, but all use the same set of Bugzilla code in the same
>+directory.
>+
>+To enable this, set an environment variable called PROJECT when
>+calling the Bugzilla CGIs. Then for each project, you can have
>+a localconfig.PROJECT (where "PROJECT" is the name of the PROJECT
>+environment variable) file for the database parameters, and a 
>+template/en/PROJECT directory (where "PROJECT" is the name of the PROJECT 
>+environment variable)

Surely you mean "value of the PROJECT environment variable"?

>+If you are upgrading and you want to use UTF-8, just turn on the "useutf8"
>+Parameter. However, realize that if you have non-UTF-8 data in your 
>+Bugzilla, it will appear unreadable. (If you just have English in your
>+database, you're safe to turn on the "useutf8" parameter, definitely.)

Even if I used the adopted English words deja vu, with accents? Or soupcon, with a c-cedilla? You should say ASCII instead of English :-)

>+Adding Individual Bugs to Saved Searches
>+----------------------------------------
>+Users now have the option in their footer of adding an individual bug 
>+number to any particular Saved Search. If you don't like having the
>+entry box there, you can disable it in your Preferences.

I don't understand what this feature does, from the description. So it probably needs clarification :-)

>+- When you mark a comment on a bug as private, the background color
>+  of the comment will change immediately. However, in order for
>+  Bugzilla to register that the comment is now private, you still
>+  have to "submit" the changes.

Isn't this dangerously misleading? Perhaps we should be using an intermediate colour, half way between white and the "private" colour.

>+- (No Bug Number) VERY IMPORTANT: If you have customized the values in
>+  your Status/Resolution field, you must edit checksetup.pl BEFORE YOU
>+  RUN IT. Find the line that starts like this:
>+
>+  bug_status   => ["UNCONFIRMED",
>+
>+  That's where you set the values for the Status field.

It took me three reads to get this. Try: "Edit this array to make it match the values you have configured for the Status field." Same for the Resolution one.

>+- (No Bug Number) Note that the email interface (bug_mail.pl) in the 
...

Shouldn't we file bugs for some of the issues with no bug number?

Gerv
We should also note that SendSQL and companions are deprecated and we expect them to be totally gone in the next release.
Attached patch v4Splinter Review
Okay, this includes everybody's very excellent comments. :-)
Attachment #211666 - Attachment is obsolete: true
Attachment #212365 - Flags: review?(LpSolit)
Comment on attachment 212365 [details] [diff] [review]
v4

>+Admins Can Impersonate Users

>+This group includes everybody in the "admin" and "bz_sudo" groups by 
>+default.

s/bz_sudo/bz_sudoers/


Fix the group name on checkin. Else this looks good to me. r=LpSolit. A second review is welcome though.
Attachment #212365 - Flags: review?(LpSolit) → review+
Okay, I checked it in and made that checkin fix. Since they're just a draft at this point, I'm not too worried about a second review at this point.

Checking in docs/rel_notes.txt;
/cvsroot/mozilla/webtools/bugzilla/docs/rel_notes.txt,v  <--  rel_notes.txt
new revision: 1.36; previous revision: 1.35
done
Status: ASSIGNED → RESOLVED
Closed: 18 years ago
Resolution: --- → FIXED
Comment on attachment 212365 [details] [diff] [review]
v4

Nice job.
Attachment #212365 - Flags: review+
Hey wait a minute. I thought the smtp support issue was unreproducable in 2.22?

in release notes:
Note: The SMTP support in Mail::Mailer 1.73 (the most recent version)
        is broken. The last known working version is 1.67.

AFAIK this is an issue in version 2.20.0 (not 2.20.1 or 2.22). See Bug 325579 

If this is still an issue has anyone told Mark Overmeer (mailtools@overmeer.net)
*** Bug 305836 has been marked as a duplicate of this bug. ***
You need to log in before you can comment on or make changes to this bug.