Review Board 1.6 Beta 1 Release Notes¶

Access Control¶

• Site divisions within Review Board.

  Review Board now supports managing several virtual instances within a single install, similar to subdirectory installs but as part of a main install’s URL. These would live on, for example, http://reviews.example.com/s/mysitename/, where http://reviews.example.com/ is the main Review Board installation.

  These site divisions can all have their own repositories, groups, review requests, users, and administrators. Data within a site division is available only to members of that site. This makes it easy to have, say, a main development Review Board, a contractor Review Board, and a QA Review Board, all separate and locked down, but without having to maintain and upgrade multiple servers.

  This isn’t completely put together yet. An administrator on a site doesn’t yet have any UI for putting together a repository or changing any settings, so it still requires a site-wide administrator to set up each site division.

• Invite-only groups.

  Groups can now be marked as invite-only. An invite-only group cannot be viewed by non-members of the group through either the web or the UI.

  A review request targeting just invite-only groups cannot be viewed unless the user is either explicitly specified on the review request or they’re a member of at least one of the targeted groups. However, if it also lists any public groups, it will be available to everyone.

  Note that users will still be able to see these review requests listed on the “All Review Requests” page, but won’t be able to access them.

• Hidden groups.

  Hidden groups are groups that are not shown unless a user is a member or otherwise knows about it (for example, has starred the group, or knows the URL). A hidden group may be invite-only, but it doesn’t have to be.

  This allows administrators to deprecate a group or to hide invite-only groups. The group won’t appear in any auto-complete, list, or the API, unless the user is a member of the group.

• Access control on repositories.

  Repositories can now be locked down such that only specific users can see the review requests on them. Users can be added to a repository’s user list directly, or indirectly by adding one or more invite-only groups. Note that access control applies to the entire repository, not specific paths within it.

  If a user doesn’t have access to a private repository, they won’t be able to see any review requests on it.

Review Requests¶

• Collapsible reviews.

  Reviews older than the most recent update to a review request that have been already been read are now collapsed by default, making it easy to skim through a long series of reviews to see what’s new. A review can be expanded by clicking the [+] on it.

  Patch by Kevin Quinn.

• One-click Ship It!

  Added a Ship It! button beside Reviews on the action bar of a review request. This will post a new review marked Ship It, with text saying “Ship it!”. It confirms you want to do this before posting, in order to prevent accidental reviews.

  Patch by Kevin Quinn. (Bug #1640)

• Delete detection for Git and Perforce.

  Deleted files in Git and Perforce are now specifically shown as having been deleted in the diff viewer, instead of showing the entire file in red.

• The review request ID is now displayed under the summary on the review request. Patch by Cristian Messel.

• Added error messages when typing an invalid reviewer (user or group). Prior to this, the invalid reviewer would just disappear from the list, leaving no indication that it was wrong. Patch by Kevin Quinn.

Third Party Integration¶

• Plastic SCM support

  We support connecting to Plastic SCM repositories. Plastic SCM is a new SCM provided by Codice Software. If you have a recent RBTools installed, it will already work with Plastic SCM checkouts. Patch by Dick Porter.

• Better custom authentication backends.

  Custom authentication backends, if written against our new auth backend API properly, will now show up automatically in the list of authentication backends in Settings, much like LDAP, Active Directory, and others.

  They can provide their own settings form, and save their settings in our settings database. This makes it easier for companies and organizations to write custom backends that tie into their services and to continue using them release to release.

  They can also specify capabilities, such as “is registration supported” or “can names, e-mail addresses, or passwords be changed.” For the latter, they can also handle updating this information server-side when the user changes it.

  See Writing Authentication Backends for more information.

User Information¶

• Improved user page.

  The user page now shows more information on the user, such as their name, e-mail address, their Gravatar, and what groups they’re a member of. Patch by Kevin Quinn.

• User info bubble.

  Hovering the mouse of a user’s name (either on a review or review request) now loads an info bubble showing the user’s name, e-mail address, and Gravatar. Patch by Kevin Quinn.

E-mail¶

• Better DKIM support for e-mails.

  Some spam filters would get caught up on Review Board’s From: header forging. The address didn’t actually match the source, causing them to sometimes flag review requests as spam.

  We now send e-mails with a Sender: header. Servers can use this to find the true sender of the e-mail, instead of assuming it’s the value in From:. By default, this is noreply@<domain>, but it can be changed in the admin UI.

Search¶

• Searching by change numbers now works. This may require a full reindex. Patch by Crystal Lok Koo. (Bug #1508)