Category Archives: Documentations

Documentations for student projects

Plans for a Checklist Extension

A Checklist Extension

I’m working on an extension to add checklists to the code review page! Checklists are really useful tools, as even the best of us can slip up on details when there’s zillions of things to think about. The B-17 Flying Fortress used a checklist to make it flyable. This extension will probably be used for the more modest goal of code convention reminders and catching common mistakes.

New Models/Tables



  • Summary (CharField): A shorter description of what the checklist item is. Example: “Make sure variables are camel-cased
  • Details (TextField): A longer description in case the item needs more detail than can be fit in one line. Can be shown on mouseover as a tooltip:
  • ForeignKey (GenericForeignKey): holds content_type and foreign_id, as described in content_type specifies whether the checklist item is associated with a user, a project (repository), or a team. On the review page, the query will grab all ChecklistItems associated with the team, the current project, and the current user.
  • Separate foreign keys (ForeignKey) to User, Group, Repository


These remember checked items per review. They are updated when a draft is saved or a review is posted.


  • Foreign key to user
  • Foreign key to the code review
  • Foreign key to the ChecklistItem
  • Checked? (BooleanField) indicates whether the item is checked or not


As a dialog box which can be dragged or minimized (to not cover the code), or perhaps slide out from the edge of the page


Added onto the review page (easy, but I think it’s useful to have the checklist visible while reviewing code)


Allows teams and projects to have shared checklists: Yes, by associating ChecklistItems with foreign keys to teams and projects

Allows individual users to add custom items to their lists: Yes, by the foreign key pointing to users

The list should be light-weight in operation, and minimal in appearance so as to keep focus on the code being reviewed:  I like the dialog box thing, personally. Open to other designs too though.

Remember checked items per review (if I save a review draft, and log-in from another computer to continue, my checklist should remember what items I’ve already checked off): Yes, using ChecklistItemMarks

Remind the user if they try to publish a review with unchecked items on their list, in case they want to keep reviewing.: Will remember in implementation

Postreview, new web api, synctransport diagram

I am a visual learner and was fortunate enough to have Steven (one of the mentors) draw on the whiteboard a visual representation for the stuff I will be working on, and some of the stuff Tina will be working on.

Clicking on the image should give you a description and my best, succinct summary of what is going on. The 2nd image on the synctransport is quite complex and thus I am not totally sure what’s going on. Please take my description with a grain of salt. The pictures are mainly here for reference in case other people would like to have a look. I may update this post if/when I get better understanding of the complexities.

Project Documentation for Per-Diff Attachments

Hello UCOSP students!

Previously, ReviewBoard only allows per-review attachments. We need a mechanism for per-diff file attachments for binary files, since the diff for binary files cannot be textually displayed. The project aims to enable this feature. The project is split into the following parts:

  1. Modify the current database structure to allowing storage of per-diff attachments
  2. Enable display of per-diff attachments on the diff-viewer page
  3. Modify the server-side JSON API to enable uploading of per-diff attachments
  4. Modify the client-side post-review tool to enable automatic uploading of per-diff attachments

Due to time constraints, only part 1 and 2 of the project have been completed, and the code is in for review (have received many reviews, now only minor code formatting to be fixed). Please see the following URL for the review:

Some explanation about the code changes for part 1 and 2:

In attachments/, two database fields are added:

diff_source_file : the original(source) file name of the particular diff

diff_source_revision : the revision number of the source file

In the attachments/, a new test case has been added to test the model change.

NOTE: The attachments/evolutions/ is added to added to apply the database model change. It is based on the Django Evolution and it must be applied to the database. Please see the documentation for Django Evolution on how to apply the change.

In the diffviewer/, code has been added to query the database for attachments that have matching source file name and revision number for each binary file diff in the review. The found attachments are added to the “context” and sent to the diff viewer page.

On the diff viewer page, templates/diffviewer/diff_file_fragment.html, code snippet has been added to display the per-diff attachments in the context, if any.

For the details of code changes, please see the review at the URL given above. If you have any questions, please feel free to contact the UCOSP mailing lists. Thanks and have a good term!