Issues and PRs > Review last approved at
Tom Azernour avatar
Written by Tom Azernour
Updated over a week ago

Dataset: Issues & Pull Requests

Entity: Pull Requests, Issues

Field ID: review_last_approved_at

Type: Datetime

Description: The datetime at which the pull request last met its minimum approval quota from approving reviews. For issues, it is the newest approval timestamp from resolving pull requests.

Source: Calculated from pull request reviews

Transformation logic:

  • Pull requests: It is the submission datetime of the last review that allowed the pull request to meet its minimum number of approving reviews to be considered approved. This field will be equal to the Review Approved At field the first time the pull request is approved. If the pull request is then rejected and re-approved again, this field will be strictly newer than the Review Approved At field.
    The minimum number of approving reviews is a configuration parameter that is usually available in each git project. If none was configured, Keypup considers that the minimum number of approving reviews is 1.
    Note that pull requests will not be considered as “approved” while there is a “request changes” review still active, even if the number of approving reviews reaches the minimum number of approving reviews. The “request changes” review must be discarded or re-requested for review first.

  • Issues: It is the newest “last approved at” datetime across all resolving pull requests. Resolving pull requests are pull requests that reference the issue via auto-closing keywords.

The table below maps the fields or logic from the source systems corresponding the most closely to the transformation carried out by Keypup:

From:

Github (PR reviews)

first_review_meeting_quota.submitted_at

Gitlab (PRs reviews)

Use the updated_at of the request approvals endpoint when the approval status is met.

Note: GitLab does not expose a submission timestamp per approval, only a timestamp indicating when the approvals endpoint was last updated. Keypup does its best to keep track of timestamps for successive approvals but those will be tracked accurately only after merge requests have been imported into Keypup.

Bitbucket (PR reviews)

first_review_meeting_quota.submitted_at

JIRA (Issues)

N/A (see transformation logic)

ClickUp (Issues)

N/A (see transformation logic)

Trello (Issues)

N/A (see transformation logic)

Did this answer your question?