Review Board 2.0 Release Notes¶

Indentation Markers in Diffs¶

In order to simplify reviews, the diff viewer has traditionally treated lines with only indentation changes as being equal. This was often helpful, but it meant that it wasn’t always obvious that a line’s indentation had changed.

The diff viewer now shows indentation changes, and differentiates between spaces and tabs. The lines are still shown as equals, to keep the diffs clean, but it’s now easy to tell at a glance what indentation changes were made to a file.

This is especially important for languages that use whitespace for blocks, such as Python.

New File Index¶

The index of files at the top of the diff viewer has been rebuilt from the ground up. In addition to just giving a list of filenames and links to the changed chunks, the new index shows:

• A graph on the left which shows the ratio of added/changed/deleted lines. The thickness of this graph indicates what percentage of the file has been altered.

• Whether files have been renamed, and the old filename if so.

• Indications for deleted or binary files.

• A list of clickable chunk dots, color-coded to represent add/change/delete.

New Diff Revision Selector¶

The interface for choosing which diff revision or set of interdiff revisions to view has changed. The new design is more compact, and is much easier to understand. The new revision selector allows viewing both individual revisions (by selecting orig and the desired revision), and viewing interdiffs (by selecting the two revisions to compare).

Reload-Free Navigation¶

As part of the new revision selector, switching between diff revisions, interdiffs, and across pages of a large diff will occur without reloading the entire page.

Visual Design Refresh¶

We’ve refreshed the visual design of the diff viewer, tweaking many of the colors to dramatically improve readability. In addition, several small bugs with alignment and spacing of various pieces of the diff view have been fixed across all major browsers.

Interdiff Improvements¶

Interdiffs could become a mess after syncing a development tree and posting a new diff. They would show changes from the sync that were unrelated to the posted change.

The diff viewer will now do its best to filter out any changes that weren’t part of the uploaded diff files.

Bug #311

Moved-Lines Detection Improvements¶

The algorithm for detecting moved lines within a diff file has been dramatically improved. The new algorithm has several improvements:

• Blank lines are now included in the moved blocks, instead of treated as two separate moves.

• Adjacent but different move regions didn’t work properly, showing only the first moved region (unless there was at least one line in between them). Now any regions anywhere work, in any order.

• Only insert/delete lines were considered for moves, which was a problem when moving some functions that resulted in replace lines (such as when one function was replaced by another). Now replace lines are factored in.

The flag indicating a moved block has also been redesigned to be cleaner and easier to read. Instead of flagging each and every line, only the first line is flagged, with a “flagpole” across the rest of the block.

Improved Rendering for New Files¶

Newly-added files would show empty line number and code columns for the left-hand side of the diff (where the original version of the file would normally go). These have been removed, and new files now take up the entire width of the box.

Easy File Downloads¶

Files shown in the diff viewer can now be downloaded in their raw, original form. A download icon is shown alongside the revision of each file. This makes it easy to fetch either the original or modified version of any file up for review.

Bug #1434

Other Diff Viewer Features¶

• Added a keyboard shortcut (r/R) to comment on the selected chunk in the diff viewer. (Bug #44)

  Patch by Edwin Zhang.

Post-Commit Review Requests¶

One of the most requested features over the past few years has been the ability to create review requests for committed changes from the web UI. Until now, doing this has required using RBTools from the command-line.

For repositories which support it, the “New Review Request” page now has a list of the committed changes, ordered from newest to oldest. This can be browsed by branch. Clicking on a commit will download the diff and change description from the repository and create a new review request.

This is currently implemented for GitHub and Subversion repositories. Support for other services and repository types will be coming in future releases.

Bug #100

Simplified Pre-Commit Workflow¶

The workflow for creating new pre-commit review requests through the web UI has also been reworked and simplified. This will now guide users through the process, asking for additional input only when necessary. In most cases, the workflow is now as simple as dragging a diff file onto the page.

Repository Quick Search¶

The old repository selector (a drop-down box) has been replaced with a sidebar which provides the capability to search for repository names. Simply click the magnifying glass and then type in the box that appears. The list of repositories will be filtered in real time as you type.

Better Validation and Errors¶

When uploading diffs through the web UI, more checking is done to ensure correctness before creating the review request. In particular, a common error case with Git repositories and diffs with abbreviated indexes will now produce a useful error message during review request creation instead of failing at the diff display stage.

Visual Design Refresh¶

• The layout of the information for review requests has been redesigned. There are now two columns. The summary, description, and testing fields are on the left, and all the other information is on the right.

  This simplifies the view, shows more of the important information at a glance, fixes up some confusing nesting issues, and will allow extensions to add new fields.

• File attachment thumbnails no longer appear scattered. They have a consistent look and size. Long filenames and captions are ellipsized, and the delete and pencil icons are now in consistent places.

  The thumbnails now do a nicer job rendering the contents. Text files in particular now have a better preview. The text contents are syntax-highlighted in the thumbnail.

Markdown for Text Fields¶

Many of the multi-line text fields in Review Board (review request description and testing done, comments, replies, and close description) now support using Markdown. This allows you to add some structure and rich formatting to your comments. The basic Markdown syntax is available, as well as a few extensions such as GitHub’s “fenced code blocks” and tables.

Most notably, it’s now possible to embed syntax-highlighted code samples or images into your comments. See the user manual for more information on how to use Markdown.

See Using Markdown for a primer on the supported syntax.

Based on work by Greg Wang. (Bug #2093, Bug #2098)

Detailed Change Descriptions¶

The “review request changed” boxes provided only basic information on what changed when publishing a draft of a review request. It wasn’t very helpful when uploading new file attachments or when changing a long description.

This has been fully rewritten to be much more useful:

• The Description and Testing Done changes are now shown as a diff, making it very easy to see what parts of the text has changed.

  Any Markdown formatting is also rendered in the diff view.

  (Bug #2045)

  

• Added or removed file attachments are shown with their thumbnails.

  The thumbnails in the change description box include a Review or New Comment link, to allow jumping directly to the review UI without needing to find the matching thumbnail at the top of the page.

  This also helps when you want to see older file attachments that have since been removed.

  

• More information is shown about the contents of new diffs.

  The total number of added or removed lines are shown alongside the diff revision, making it easy to see just how big the change is.

  A file listing is also shown for the diff, along with the same icons now used in the diff viewer to show the complexity of the changes made to the files.

  

• The other fields, like Branch and Depends On, are shown in a way that makes it much easier to see what has changed.

  Some of the fields also show more information than they used to. Depends On, for example, now shows the summaries of the review requests.

Custom fields provided by extensions will benefit from these updates as well, and can also take advantage of the new API to customize how the updates are displayed.

Changing Issue Status¶

Issues can now be marked as fixed or dropped and reopened by the user who created the comment, in addition to the owner of the review request.

Based on work by Niklas Hambuechen. (Bug #2713, Bug #2888)

Other Review Request Features¶

• Expand collapsed reviews when jumping to issues from the summary table.

  When clicking on issues in the issue table, if the containing review was collapsed, it will now be opened before jumping to it.

  Patches by Hiroki Gohara and Yazan Medanat. (Bug #3770)

• Added “Last Diff” timestamp to review requests.

  This change adds an additional timestamp to the top of the review request to show the timestamp of the most recent diff update.

  Patch by Vlad Safronov.

• The Depends On field now shows a strikethrough for dependencies that have been closed. (Bug #3200)

  Patch by Olessia Karpova.

• Interdiff link on the draft banner. (Bug #3189)

  When uploading a new diff to an existing review request, the draft banner will now show a Show changes link that will take you to an interdiff between the last published diff and the newly uploaded diff.

  Patch by Tomi Äijö.

Bulk Close for Review Requests¶

There’s a new column available in the dashboard that provides a checkbox for selecting rows of review requests. This allows for selecting one or more review requests and closing them, right from the dashboard.

This is particularly useful for administrators, or users with close privileges, to clean up review requests left open by other users.

You can find the new column by clicking the pencil icon on the upper-right of the dashboard.

Bug #579

Better Issue and Ship-It Tracking¶

If there are any open issues remaining on a review request, they will be shown in place of the Ship It count in the dashboard. Any Ship Its issued on the review request will remain hidden until all issues are resolved.

This makes it easier to see what work still remains at a glance, and to give a better idea if a Ship It really means Ship It.

Improved Dashboard Sidebar¶

The dashboard sidebar is now better organized, neatly categorizing items under Incoming and Outgoing sections. There’s no longer a bunch of bold items that double as links and sections.

The current dashboard view is also highlighted, making it easier to see what you’re looking at.

Other Dashboard Features¶

• There’s a better set of default dashboard columns for new users. These are, in order:

  • Select Rows

  • New Updates

  • Ship It!

  • My Comments

  • Summary

  • Submitter

  • Last Updated (Relative)

  Existing users won’t see their columns change. If they want to use the new columns, they can click the pencil on the top-right of the dashboard and customize their columns.

• Added a Diff Size column to the dashboard, which shows the number of inserted and deleted lines in the uploaded patch. (Bug #48)

• Submitted review requests are now included in the Starred Reviews page of the Dashboard.

  Previously, any review requests that a user had starred would be removed from this page as soon as the request was closed. Submitted and discarded review requests are now included in this page along with open ones.

  Patch by Mary Elaine Malit. (Bug #1075)

• Discarded review requests are now shown in the All Review Requests page. (Bug #576)

• The dashboard frame now takes up the full page size, instead of fitting the content and possibly scrolling parts off the page.

Generic Text Review¶

Text files attached to review requests can now be reviewed just like a diff. Their contents will be syntax-highlighted when possible, allowing for easier review of standalone snippets of code, SQL data dumps, XML files, or anything else.

Comments can be made on single lines, or they can span multiple lines. Any commented lines will appear along with the comment in the review.

Bug #1702

Markdown Review UI¶

Markdown files uploaded as file attachments can now be reviewed in detail. The uploaded file will display both the source text and the rendered HTML. Comments can be added to either the source or rendered result, and the corresponding lines will appear in the review.

Based on work by Aamir Mansoor.

Visual Design Refresh¶

Review UIs now look a lot cleaner and more compact. In previous releases, a mostly empty review request box would appear above the review UI, taking up valuable space. This has been removed, providing more focus on the text, image, or PDF being reviewed.

Better Issue and Ship-It Tracking¶

Similar to the changes to the “Ship it!” column in the dashboard, improvements were also made for reviews. Now, if a reviewer marks Ship It and opens issues, the “Ship It!” will be replaced by “Fix it, then Ship it!” until all the issues are closed. Once the last issue is closed, it will update to “Ship It!”

Thumbnails in the Review Dialog¶

File attachment comment thumbnails (like image excerpts) are now shown in the “Edit Review” dialog.

When opening the Review dialog (either through the top-level Review action or the Edit Review button on the banner), any comments on file attachments will show the comment thumbnail along with the comment text (for example, the selected region of an image). This more closely mirrors what the review will look like once published.

Per-Page Static Media Bundles¶

Static media bundles (defined by css_bundles and js_bundles on an Extension) can be applied to specific pages by specifying an apply_to field in the bundle definition. This field takes a list of URL names that the bundle should be loaded on. It works like the default bundle in that the bundles don’t have to be manually loaded in a template.

Pre-Defined URL Name Lists¶

There’s now a few useful lists of URL names that an extension can import that can be used for any apply_to fields, to help ensure hooks or static media bundles apply to the necessary pages.

This includes diffviewer_url_names, reviewable_url_names and review_request_url_names, which can be imported from reviewboard.urls.

LessCSS Files¶

• Built-in constants

  Any .less file can now make use of @RB_MAJOR_VERSION, @RB_MINOR_VERSION, @RB_MICRO_VERSION, @RB_PATCH_VERSION, @RB_IS_RELEASED, @DEBUG, and @STATIC_ROOT macros.

  These are useful in LessCSS macro guards when you may need to alter a rule depending on the version of Review Board or whether it’s a production install.

  Extensions can also use @STATIC_ROOT as the base path for loading in definition files provided by Review Board. For example, @{STATIC_ROOT}/rb/css/defs.less.

  These apply to extensions when running in development mode and or when packaging the extension.

• Bundled definitions

  LessCSS files can now import @{STATIC_ROOT}/rb/css/defs.less, which provides a number of definitions and macros to help match the style of Review Board.

AccountPagesHook and AccountPageFormsHook¶

Extensions can add to the new My Account page through the new AccountPagesHook and AccountPageFormsHook. These create new page sections in the My Account page and add to existing page sections, respectively. See the documentation for more information on using these.

AuthBackendHook¶

The new AuthBackendHook allows extensions to provide new authentication backends. These will be available in the list of authentication backends that the administrator can choose from. This is now the preferred way of adding custom authentication backends, rather than using Python entrypoints.

The auth backend will be registered when the extension is enabled, and unregistered when disabled.

See the documentation for information on using this.

DashboardColumnsHook¶

Extensions can add new columns to the dashboard and to other datagrids using the new DashboardColumnsHook. These can be used to display custom information on each row of the dashboard, using, for example, custom data stored on a review request by the extension.

DashboardSidebarItemsHook¶

The old DashboardHook has been replaced by DashboardSidebarItemsHook, which offers an improved way of adding content to the dashboard’s sidebar.

Instead of only supporting links to URLs, this can support content of any type by making use of extensible subclasses of rb2.0:reviewboard.datagrids.sidebar.BaseSidebarItem. We provide built-in classes for named sections (rb2.0:reviewboard.datagrids.sidebar.BaseSidebarSection) and links (rb2.0:reviewboard.datagrids.sidebar.SidebarNavItem). New subclasses can be written for rendering any custom template.

Field and FieldSets¶

Extensions can now add additional fields and groups of fields to review requests through ReviewRequestFieldsHook and ReviewRequestFieldSetsHook. See the documentation for more information on using these.

Custom fields will have their contents saved and published along with drafts. They will also be shown in the “Review request changed” boxes. Fields can provide custom rendering for their changed in these boxes if they need to.

ReviewRequestApprovalHook¶

Companies that need to define their own approval logic can subclass ReviewRequestApprovalHook and implement the is_approved() method to calculate if the provided review request is approved. This value will be reflected in the API, and will be accessible to any extensions that want to operate on approval.

SignalHook¶

Extensions that need to listen to signals can now use SignalHook instead of managing their own signal connections.

SignalHook takes the signal and a callback as arguments, and an optional sender. It will then connect to that signal, and disconnect when shutting down the extension.

Template Hooks for Login and Registration Pages¶

There are new before-login-form, after-login-form, before-register-form, and after-register-form template hooks that can be used to render content before or after the login or registration forms. This can be used to provide further instructions or other options.

UserPageSidebarItemsHook¶

A new extension hook has been added for adding links to the sidebar on the user page (/users/<username>/). UserPageSidebarItemsHook is just like the new dashboard sidebar hooks listed above, but targeted for the user page instead.

Custom Login Instructions¶

Any custom authentication backend can now set login_instructions to the text to display on the login page. Installations that need something beyond the default instructions can subclass their preferred authentication backend and override these.

Populating Users on API Lookup¶

An AuthBackend.query_users() method was added, which can populate the database based on a user lookup query.

This is called when querying User List Resource before any results are returned from the database. This can be used to query a backend server or database to fetch any matching users and store them in the database.

Extensions can raise a UserQueryError if this fails, which will be reflected in the web API through 226 - User Query Error.

Patches by Mark Côté.

Custom User Filtering¶

An AuthBackend.search_users() method was added, which is called when querying a list of users using the API. This function can override the query to perform a lookup with the provided query string in whatever way is most appropriate for the backend.

This can be used, for example, to filter out users not matching certain criteria, or to change which fields are matched.

Patch by Mark Côté.

New Initialize Method¶

Instead of overriding Extension.__init__() and passing arguments to the parent method, extensions can now simply override initialize(). This doesn’t take any arguments, and there’s no need to call the parent method.

This means instead of this:

class MyExtension(Extension):
    def __init__(self, *args, **kwargs):
        super(MyExtension, self).__init__(*args, **kwargs)

        # Initialization here

You can just do this:

class MyExtension(Extension):
    def initialize(self):
        # Initialization here

New extra_data Fields¶

extra_data fields have been added to DiffSet, DiffSetHistory, FileDiff, Group, Review, ReviewRequest, and ReviewRequestDraft.

These fields accept structured Python data and serialize it to JSON. They accompany the existing extra_data fields on Profile and Repository.

Extensions can now store state on any of these objects for later use. The values can also be accessed and manipulated through the API. See Extra Data for Resources.

New Signals¶

• There are two new signals that can be used by extensions to operate when settings have been changed.

  • site_settings_loaded signal (provided by rb2.0:reviewboard.signals) is emitted after Review Board loads its settings.

  • settings_saved (provided by djblets.extensions.signals) is emitted for an extension when its settings have been saved.

• Added review_request_publishing, review_publishing, and reply_publishing signals.

  These signals are emitted before the publishing process starts on review requests, reviews, and replies. Extensions can connect to these to perform pre-publish validation. They can raise a PublishError to abort the publish.

  The error message provided to PublishError will be reflected in the API’s error message.

  Patch by Mark Côté.

Access to Extension Instances¶

Extension code often needed to access the instance of the extension, but that instance wasn’t always immediately available. That meant that they’d have to jump through hoops, querying for the extension using the extension manager.

Extensions can now access an instance attribute on their Extension subclass, which will point to the running instance of the extension. This will be None if the extension is not enabled.

SettingsForm.settings¶

Subclasses of SettingsForm can now access a settings attribute, which points to the extension’s settings. This is useful for custom load() and save() methods that need to access the settings in some way.

Custom Context Processors¶

Extensions can now provide custom Django context processors, which will add variables to all rendered templates. This is useful when you need to provide data to pages not directly rendered by an extension, such as the login page.

Extra Context for TemplateHook¶

TemplateHook now accepts an extra_context argument that can be used to populate the template with custom variables.

TemplateHook subclasses can also implement get_extra_data() to dynamically generate data for the template. Previously, they had to override render_to_string() to provide any custom data.

Improvements to Configuration Pages¶

Configuration pages for an extension can now use the Django admin widgets that are normally reserved for forms in the Django administration UI. These contain useful widgets such as SplitDateTimeWidget and the side-by-side, filterable lists of items.

Miscellaneous Changes¶

• Moved the base-after-navbar template hook.

  This has now been moved to right after the navbar, instead of further down the page, allowing extensions to provide new UI immediately below the navbar.

• Custom middleware can now take an optional extension parameter.