PulseUno Code Review FAQ

This section presents answers to some frequently asked questions about PulseUno (formerly Pulse) Code Review.

Who can start (or update) a PulseUno Code Review?

A: Any user who can access the depot, stream and/or issue can start (update) a Code Review.

How can I tell who created (or updated) my Code Review?

A: In the Activity section of the review, you can see who committed what changes to the review:

In this case, Emily started the code review, and the author of the transaction was Tony. The code review was then updated by Logan, and the author of that transaction was Lindsay.

When adding reviewers to a Code Review, why don’t I see all AccuRev users listed?

A: AccuRev users must have logged into PulseUno at least once to be available as a reviewer. It’s possible the user you are looking for has never logged into PulseUno. A PulseUno administrator can see which users have logged into PulseUno.

Can Code Reviews contain changes from multiple users? How can I tell which user made which change? If there are multiple contributors, who is the owner of the review?

A: Yes, PulseUno Code Reviews can contain changes from multiple users (just as an AccuWork issue can contain transactions from multiple users). The author of the change will be listed next to each transaction in the review:

The owner of the Code Review will be the author of the first transaction. In this case, the owner is Tony.

How do my depot and element ACLs work with PulseUno? I don’t want users to see code that is restricted in AccuRev.

A: PulseUno Code Reviews respect all ACLs. Elements that are part of a review will not appear for users that do not have access. It is possible a review will appear empty if the user does not have access to any element. It is up to the author to select appropriate reviewers who have access to the elements of the code review.

How are removed versions represented in a Code Review? We regularly remove versions of elements from our issue change packages, via the GUI and via the CLI cpkremove command.

A: When versions are removed from a change package, the elements do not disappear from the Code Review. Rather, they are marked as CPK Removed with a strike through the element name. Removing a version constitutes a distinct transaction in the Change Package History, and it is represented as a distinct changeset in the PulseUno Code Review.

Does the “Code Review” tab in the AccuRev GUI’s Preferences dialog pertain to PulseUno Code Review?

A: No, the GUI preferences for Code Review relate only to Crucible Code Review (a third party product). There are no GUI preferences or settings relating to PulseUno Code Review (a product that is bundled with AccuRev 7.3 and later).

In the Requests section where I see information about my issue, what issue fields are displayed? Can I change which fields are displayed?

A: The Requests section displays information about the associated issue. It also contains a link to open the issue in the WebUI. The issue information that is displayed comes from these four default schema fields:

These defaults are specified in the following properties defined in <ac-install>/pulse/conf/startup.properties:

You can specify different issue fields (except for issueNum) by editing the startup.properties file. For example, if your company prefers to display the user who created the issue rather than the user to whom the issue is assigned, you can just change the last line shown above to:

Note: These settings are global for PulseUno and must be made by a system administrator. They are not specific to an AccuRev server or to a depot.

How can I control the voting on reviews and whether reviews are automatically approved or rejected?

A: PulseUno defines four different “rules” to control this logic. PulseUno administrators can configure different rules for different depots. The four rules available are:

• defaultRule.js - approve/reject based on first reviewer’s opinion

• leadsOnly.js - approve/reject based on first lead reviewer’s opinion

• majorityDecides.js - approve/reject based on majority of reviewers’ opinions

• allMustApprove.js - approve if all reviewers like it (i.e., approve); send for rework if any reviewer doesn't like it (i.e., requests changes)

How can I use the Code Review state to control which issues get promoted through my stream hierarchy?

A: For streams that have workflow rules defined, the Code Review state can be incorporated into stream entry or exit rules in order to restrict issue promotion to only those issues that have passed code review.

The Code Review state can also be queried in the server_preop_trig trigger to restrict issue promotion.