We’ve released Djblets 3.1, our collection of production-quality add-ons for Django.
This release features:
djblets.registries, djblets.secrets, and djblets.siteconfig modelsFor complete details, see the release notes.
These are exciting times, right? While everyone is preparing for the coronavirus, we’ve been preparing for Review Board 4.0 beta 1.
And the coronavirus.
The shelves are getting pretty empty in my local grocery store, but I’ve kept my sanity.
We have an internal target date for 4.0 beta 1, which is coming up very soon, but we’re not prepared to release that just yet. Still a couple factors that might need to delay a week.
This beta will feature:
We’re working on the final bits of the administration UI, and expect to be done by end of next week. Everything is in place, with the exception of the Integrations, Extensions, and Security Center pages. But that’s it!
We’ve also been finishing up the work to make our third-party integrations (Travis-CI, Asana, Jenkins, etc.), Review Bot, and Power Pack all compatible with Review Board 4.0, Django 1.11, and Python 3. These are the last big blockers before release.
After all that is done, beta 1 will be a go!
(Assuming none of us get the coronavirus.)
If you are building custom extensions, please get ready to test this beta. Let us know if you plan to test so we can coordinate with you and give you a heads up on what may change.
RBTools 2.0 features full support for multi-commit review requests. We’ve had the bulk of this work done for a while, but have been really thoroughly testing it in preparation for a beta, which will go out alongside Review Board 4.0 beta 1.
This week, we’ve finished up the work to apply patches from a multi-commit review request (giving the ability to apply all commits sequentially or squash into a single commit), and to fully land changes.
We’re wrapping this up soon. If you test Review Board 4.0 beta 1, you’ll need RBTools 2.0 beta 1.
What else, what else..
We’re continuing to work toward improving our accessibility story in Review Board. While we’re nowhere close to where we want to be yet, we’ve amended our policies around new UI components to ensure that keyboard usage and ARIA roles are a first-class citizen in any designs.
If you make use of any assistive technologies, such as screen readers, we’d love to talk to you and get your feedback on a few things!
Review Board 4.0 will be making it easier to glance over file attachments for video files. Just like file attachment thumbnails for images and text files give you a preview of the contents, they’ll soon give you a preview of the video as well.
Hovering the mouse over these thumbnails will cause the video to play (muted) until you move the mouse away. Hovering over them again causes the video to resume from where it left off.
This is great if someone’s using video files to demonstrate their feature. We’re hoping to make this the start of some useful UI around videos.
This past week saw the development of several new accessible CSS/JavaScript components, which can be used by extensions:
We’ve historically had a few different ways to show buttons. Any <input type="button" />, <input type="submit" />, or anything with the .btn CSS class would have a consistent appearance, and could be modified by a set of additional CSS classes.
This has been revised to include <button> (which we oddly did not have before) and anything using the .rb-c-button CSS class (the successor to .btn, which is now deprecated).
A button group (.rb-c-button-group in LessCSS) is a collection of buttons, packed together either horizontally or vertically, providing an almost toolbar appearance.
The new RB.MenuView (JavaScript) and .rb-c-menu (LessCSS) component manages a pop-up menu that can be shown or hidden as needed. It supports full keyboard navigation and ARIA attributes for accessibility.
We’re working on moving to this in every place that involves a pop-up menu, including review request actions (like “Update” and “Close”) and the Account, Support, and Follow menus in the upper-right of pages.
RB.MenuButtonView (JavaScript) and .rb-c-menu-button (LessCSS) implements a type of button that displays a pop-up menu when clicked.
There are two main ways this can be used:
The later is great when you want to offer a common action, but make alternative actions easily available.
Like the new pop-up menus, these provide full keyboard navigation and ARIA attributes for accessibility, and are a great building block for extensions to use.
We hope to provide full documentation at a later time on the standard library of UI components we’re building.
KGB is our Python module for unit tests, which provides the ability to spy on any function and track the calls and results, or override the behavior. It’s incredibly powerful, and we make heavy of use of it in Review Board and all our other projects.
We’ve just fixed up KGB to work with Python 3.8, so we’re preparing for a release pretty soon.
If you’re a Python developer, check out KGB. Tell your friends. Give us some feature requests. Honestly, it’s pretty complete these days, but we need more reasons to bump the version number.
Alright, that’s enough for this ChangeLog.
We may skip next week’s ChangeLog to focus on finishing beta 1, unless we have anything really interesting to report.
If you want to know more, have any questions, or are curious about anything else, please reach out on our community forum.
We’re also on Reddit (/r/reviewboard), Twitter, Facebook, and YouTube if you want other ways to keep up with Review Board and Beanbag.
We’ve just gone live on a major update to the billing capabilities in RBCommons.
With all the fraud and stolen credit card numbers out there, it’s no surprise that a lot of people wanted to try RBCommons to see if it was the right fit but weren’t comfortable providing their credit card information right away.
We’ve changed our trial so that you can sign up with only your name and e-mail address, and if you decide to keep using RBCommons, you can add your billing information later.
Many companies have a dedicated person for dealing with billing administration for services. Until now RBCommons has only had a single team administrator role, which provided access to both the billing information as well as everything else for the team. We’ve split up these responsibilities into new user roles:
All team administrators have been updated to become Team Owners. To change a user’s roles, visit your Team Administration → Users page and click the pencil icon beside a user.
Many countries require invoices to contain certain information, such as an official business name and address, or a tax ID. RBCommons now allows you to add this information in Team Admin → Account and Billing, and it will show up on your invoices.
If you’re a business located in the EU, you can put in your VAT ID and we’ll make sure that the generated invoices contain everything you need for your VAT filings.
If your country has invoice requirements that we haven’t met, please contact us.
You can now add additional e-mail addresses where you’d like any and all billing e-mails sent to. This is really useful if you have a purchasing department or some users who need to track receipts but don’t need access to RBCommons.
You can set these over in Team Admin → Account and Billing → Billing E-mails.
As part of this, we’ve made a small update to our Privacy Policy to list Quaderno as a third-party service used in our billing process. This is a good time to review your privacy choices under My Account → My Privacy Rights.
This has been in the works for a long time, and we’ll be iterating on it based on your feedback. So how’s it working for you? Let us know through the Need Help? button in the bottom-right of any page (opt in to Intercom in My Account → My Privacy Rights) or send us an e-mail at support@beanbaginc.com.
Welcome back, everyone! We’re here with another ChangeLog, this time focusing on a couple things that just wrapped up: This semester’s student projects, and a series of behind-the-scenes repository configuration improvements.
Last month, we talked a bit about the CANOSP student program run out of the University of Alberta, and showed off some of the work our CANOSP students have done on Review Board.
They’ve all been hard at work improving our Review UI support (custom review UIs for different types of file attachments), building up both the underlying capabilities of a Review UI and creating prototypes of new UIs for new types of files.
They’ve just wrapped up their semester and completed their final demo videos. We’d like to show off their hard work.
Nicole’s focus has been the underlying Review UI support, allowing Review UIs to be more dynamic and to not be limited to a single URL. This work has been a backbone of other student projects this semester, so we’re covering it first.
On top of this, she’s built a new Review UI for more easily viewing JSON files, both in their source form and in a structured tree-based form.
Adil built a series of new Review UIs designed for reviewing:
These have come along really nicely, and show the power of our Review UI support (and the work done by Nicole Hagerman).
Ceegan split his time between some improvements to our diff viewer and to our Review UIs as well:
.min.js files).zip, .rar, etc.).A good chunk of my own time these past few weeks has been to rework the code behind the repository configuration page. Along with an assortment of bug fixes, we’re working to make it easier to configure plain (non-GitHub/Bitbucket/etc.) repositories.
Historically, plain repositories all shared the same set of configuration fields. You had your “Path” field, “Mirror Path,” “Username,” “Password”. A few had special fields like Perforce’s “Use ticket-based authentication,” but they were baked into the repository form and dealt with specially. Third-party repository support couldn’t add their own fields, and administrators had to translate concepts like a Git Clone URL into our concept of a “Path.”
As of the upcoming Review Board 3.0.16, each type of repository will be able to provide its own configuration form. For instance, down the road, Git repositories will have a dropdown for selecting CGit, GitWeb, etc. as the repository content access method, instead of forcing people to type in a cryptic URL.
Here’s a mockup:
Bottom line: It’s going to be easier to configure repositories in upcoming releases.
There’s a lot of under-the-hood work that’s been done to enable this, and that work is also going to lead to some future improvements we’re looking forward to building in the Review Board 5.0 timeframe. Can’t wait to write about it.
That’s another week done. We’ll be back next week!
So what do you think so far? Are the ChangeLogs interesting? Boring? Is there something else you want to hear about? Please let us know on the community forum so we can improve these going forward.
We’re also on Reddit (/r/reviewboard), Twitter, Facebook, and YouTube if you want other ways to keep up-to-date.
The new major release of Power Pack 3.0 brings the ability to diff PDF documents, comparing how the text of the document changes between revisions, and makes it easier to manage your license subscriptions.
This can drastically cut down on the time needed to read through documents as the author takes in suggested edits from reviewers. Just like a code diff, any text changes made in a document are shown inline in the PDF, color-coded for easier viewing.
A handy new sidebar view catalogues all the changes made throughout the document, so there’s no need to carefully scrutinize as you scroll.
If you do need to scroll, a new “Lock scroll” checkbox gives you control over whether the documents should scroll in sync, or scroll individually.
In order to enable diffing support for PDFs, you will need a PDF document that contains text information embedded in the document (such as when printing to PDF or using OCR on a scanned document). It’s also important to update the existing PDF file attachment with the new document, instead of creating a brand new upload.
We’ve revamped the Power Pack configuration page to better show the status and health of your license, how quickly the expiration date is coming up or whether you’re hitting your user cap.
The new “Manage your license” button takes you straight to our license portal where you can renew your license, convert to a yearly subscription, add additional users, and more.
Power Pack now checks for updates to your license automatically when viewing the Power Pack configuration page, and will install any new license it finds. You no longer need to download and install new license files from the license portal yourself.
We’ve sorted out some crashes and visual glitches in reports, as well as a compatibility problem with AWS CodeCommit. The full list of changes are in the release notes.
Get started today with a 30 day trial license. After 30 days, enjoy a complimentary license for up to 2 users forever, or purchase a license for the rest of your organization.
As a team grows, it often becomes the case that more developers need to assume more specialized roles in the code review process. Not just that of developer and reviewer, but also that of a manager of sorts, helping to keep the review process going and to keep the process tidy.
We’re introducing a few new special user permissions, designed to give users a subset of an administrator’s abilities. These can all be set in the Team Administration page by clicking the pencil icon next to team member.
The first permission, “Can close or reopen review requests from other users,” enables a user to help keep the list of review requests tidy by toggling whether a review request is currently open. If you’re not auto-closing review requests, if you have review requests open from former team members, or if you’re managing an open source project on RBCommons, this can be quite handy.
The second permission, “Can edit review requests from other users,” allows a user to modify a review request on someone else’s behalf. They can upload diffs, edit fields, and so on. The changes currently appear as if they’re from the owner of the review request.
The final permission, “Can post review requests as other users,” is most useful for scripts. In cooperation with RBTools (using rbt post –submit-as), a script can post a review request on another user’s behalf, perhaps when a change is committed to a special branch, or after a sandbox operation passes.
We’ve been piloting these permissions with some projects for a while now. Please let us know how they work for you, and if you have any questions or problems.
Tonight, we’ve released a huge set of bug fixes and feature improvements for RBCommons that should improve your code review experience.
We’ve fine-tuned many parts of RBCommons to give you a faster experience.
Editing Markdown text should now feel as fast as editing plain text. The lag that would sometimes appear has been fixed.
The dashboard now loads a lot faster when using the People, Groups, or To Me columns.
We’ve also improved performance in our API. RBTools and various operations on the site should be much faster now.
Markdown is now completely optional. By default, all text fields on review requests and comments on reviews will be in Markdown mode, as before. However, you’ll now be able to turn off Markdown while editing, saving as plain text.
You can also choose to disable Markdown by default for all fields in your My Account page. Simply uncheck “Always use Markdown for text fields.”
Note that if Markdown is enabled by default, then all fields will start off editing in Markdown mode. Any plain text will be escaped first.
Along with this, we’ve fixed a number of escaping and rendering problems with Markdown text, particularly for text coming from a commit.
The diff viewer now supports selecting and copying the text within either column in the diff viewer, without that selection covering code from the other column.
Previously, selecting worked like it did for any table in a web page, in that the selection would span both columns, making it impossible to get the text out cleanly. With this new support, you can safely copy a block of text from the original or modified file and paste it into your editor.
We’ve reduced how much e-mail you’ll receive in certain cases. For instance, if a review request is updated to add new reviewers, without altering any other fields or introducing a new diff, only the new reviewers will be notified of the update.
We’ve also introduced an option to let you opt out of any e-mails triggered by your own actions. To opt out, head over to the My Account page and uncheck “Get e-mail notifications for my own activity.”
We’ve fixed nearly 40 bugs across the site, covering issues with repository compatibility, diff generation, usability, e-mail notifications, and more.
We’ve launched a new feature today for simplifying your code review workflow.
If you’re using GitHub, Bitbucket, or Google Code, RBCommons can now automatically close your review requests when you push your commits to your repository, making use of the service’s “post-commit” hooks. You’ll no longer need to click Close -> Submitted, saving time and keeping your dashboard clean.
Usage is simple
Once you’re set up (and we’ll go into that in a minute), all you need to do is include the following in your commit message:
Reviewed at https://rbcommons.com/s/<your-team>/r/<id>/
Or:
Review Request #<id>
Just commit, and your review request will be automatically closed, along with a message containing the commit revision and which branch it was committed to.
Setting this up
Setup depends on which service you’re using for your repositories, but we’ve worked to make it pretty simple.
We’ve added some new buttons to your Team Administration -> Repositories page. You’ll see a “Hooks” button next to any supported repository. Click that, and you’ll see instructions on turning this feature on for your repository. In just seconds, your repository will be set up!
This feature is still new, but has been undergoing testing for several weeks. If you hit any snags, let us know and we’ll help get you going.