@cesar-richard/git-connector-sdk 2.7.0 → 2.8.0

package/README.md

@@ -317,9 +317,11 @@ cross-provider work is consolidated: the issue is the pivot.
 
 ### PR review status (`reviewStatus`)
 
-Each `LinkedActivity` carries an optional `reviewStatus` field with 8 possible
-values, computed server-side from the PR's state, draft flag, requested
-reviewers, and review history:
+`reviewStatus` is carried by both `LinkedActivity` (on `/v1/work-items`) and
+`Activity` (on `/v1/activities`), computed server-side from the PR's state,
+draft flag, requested reviewers, and review history. It has 8 possible values —
+plus `null` on `/v1/activities` for items of type `issue`, which are not under
+review at all:
 
 | Value | Meaning |
 |---|---|
@@ -350,6 +352,42 @@ for (const wi of data.items) {
 }
 ```
 
+### Who is reviewing what (`requestedReviewer`)
+
+`/v1/work-items` only reaches PR/MR that are **linked to an issue**. A merge
+request with a requested reviewer but no issue link is invisible there — which
+is exactly the case most likely to go unnoticed. `/v1/activities` has no such
+constraint, and carries the same review fields: `requestedReviewers`,
+`requestedReviewersResolved`, `awaitingReview`, `reviewRequestedAt` and
+`reviewStatus`.
+
+Filter with `?requestedReviewer=<login>` (CSV, case-insensitive, OR within,
+AND with every other filter). Do not confuse it with `/v1/work-items`'
+`?reviewerIs`, which matches items someone has **already reviewed**, not those
+**awaiting** their review.
+
+```ts
+const { data } = await client.GET("/v1/activities", {
+  params: {
+    query: {
+      requestedReviewer: "cesar",
+      state: "open",
+      viewer: "cesar",
+    },
+  },
+});
+for (const a of data.items) {
+  const names = (a.requestedReviewersResolved ?? []).map(r => r.name ?? r.login);
+  console.log(`${a.url} — ${a.reviewStatus} — ${names.join(", ")}`);
+}
+```
+
+To cover every alias of the same person, use `?reviewerIdentity=<id>` — the
+reviewer-side counterpart of `?identity` (which filters on the author). The two
+reviewer parameters are mutually exclusive, as are `?identity` and `?author`.
+GitLab reviewer logins are sometimes numeric strings (`"7066488"`); those are
+usernames like any other, and `/v1/identities` resolves them normally.
+
 ---
 
 ## API surface

package/dist/schema.d.ts

@@ -247,6 +247,20 @@ export interface components {
                 createdAt: string;
                 updatedAt: string;
                 mergedAt: string | null;
+                /** @description Provider-side logins requested as reviewers (GH `requested_reviewers`, GL `reviewers`). Always empty for issues. GitLab usernames may be numeric strings — those are usernames like any other, not ids. Same field and semantic as LinkedActivity.requestedReviewers, so an activity carries it whether or not it is linked to an issue. */
+                requestedReviewers: string[];
+                /** @description Resolved form of `requestedReviewers` (id + login + name + email). Subset: only the logins the GitLab user cache could resolve. Fall back to the raw login from `requestedReviewers` for the rest. */
+                requestedReviewersResolved?: {
+                    id: string;
+                    login: string;
+                    name: string | null;
+                    email: string | null;
+                }[];
+                /** @description True when the activity is open AND has at least one requested reviewer who has not yet responded. Always false for issues. */
+                awaitingReview: boolean;
+                reviewRequestedAt: string | null;
+                /** @description Review lifecycle bucket, or null for issues — an issue is not under review, so no bucket applies. Pass ?viewer to split 'open-awaiting-my-review' from 'open-awaiting-other-review'; without it, a pending review always reads as 'open-awaiting-other-review'. */
+                reviewStatus: ("draft" | "open-no-review" | "open-awaiting-my-review" | "open-awaiting-other-review" | "open-changes-requested" | "open-approved" | "merged" | "closed") | null;
                 authorIdentity?: {
                     id: string | number;
                     displayName: string;
@@ -276,6 +290,20 @@ export interface components {
             createdAt: string;
             updatedAt: string;
             mergedAt: string | null;
+            /** @description Provider-side logins requested as reviewers (GH `requested_reviewers`, GL `reviewers`). Always empty for issues. GitLab usernames may be numeric strings — those are usernames like any other, not ids. Same field and semantic as LinkedActivity.requestedReviewers, so an activity carries it whether or not it is linked to an issue. */
+            requestedReviewers: string[];
+            /** @description Resolved form of `requestedReviewers` (id + login + name + email). Subset: only the logins the GitLab user cache could resolve. Fall back to the raw login from `requestedReviewers` for the rest. */
+            requestedReviewersResolved?: {
+                id: string;
+                login: string;
+                name: string | null;
+                email: string | null;
+            }[];
+            /** @description True when the activity is open AND has at least one requested reviewer who has not yet responded. Always false for issues. */
+            awaitingReview: boolean;
+            reviewRequestedAt: string | null;
+            /** @description Review lifecycle bucket, or null for issues — an issue is not under review, so no bucket applies. Pass ?viewer to split 'open-awaiting-my-review' from 'open-awaiting-other-review'; without it, a pending review always reads as 'open-awaiting-other-review'. */
+            reviewStatus: ("draft" | "open-no-review" | "open-awaiting-my-review" | "open-awaiting-other-review" | "open-changes-requested" | "open-approved" | "merged" | "closed") | null;
             authorIdentity?: {
                 id: string | number;
                 displayName: string;
@@ -3785,6 +3813,12 @@ export interface operations {
                 identity?: string;
                 /** @description When '1', enriches each activity with `authorIdentity: { id, displayName } | null`. */
                 withIdentity?: string;
+                /** @description CSV of GitHub/GitLab logins requested as reviewers (case-insensitive, OR within, AND with the other filters). Answers 'what is waiting on this person's review?' — including PR/MR not linked to any issue, which `linkedActivities[]` on /v1/work-items cannot reach. Distinct from /v1/work-items' `reviewerIs`, which matches items ALREADY reviewed rather than awaiting review. Mutually exclusive with ?reviewerIdentity. */
+                requestedReviewer?: string;
+                /** @description Filter by the requested reviewer's user identity ID, resolving all of its aliases. The reviewer-side counterpart of ?identity (which filters on the author). Mutually exclusive with ?requestedReviewer. */
+                reviewerIdentity?: string;
+                /** @description Login (case-insensitive) used to compute `reviewStatus`. When the viewer is among a PR/MR's requested reviewers and no verdict is active, reviewStatus is 'open-awaiting-my-review' instead of 'open-awaiting-other-review'. */
+                viewer?: string;
                 /** @description CSV: open,draft,merged,closed,unknown. Default returns all states. */
                 state?: string;
                 /** @description CSV: pr,mr,issue. Default returns all. */
@@ -3827,6 +3861,20 @@ export interface operations {
                             createdAt: string;
                             updatedAt: string;
                             mergedAt: string | null;
+                            /** @description Provider-side logins requested as reviewers (GH `requested_reviewers`, GL `reviewers`). Always empty for issues. GitLab usernames may be numeric strings — those are usernames like any other, not ids. Same field and semantic as LinkedActivity.requestedReviewers, so an activity carries it whether or not it is linked to an issue. */
+                            requestedReviewers: string[];
+                            /** @description Resolved form of `requestedReviewers` (id + login + name + email). Subset: only the logins the GitLab user cache could resolve. Fall back to the raw login from `requestedReviewers` for the rest. */
+                            requestedReviewersResolved?: {
+                                id: string;
+                                login: string;
+                                name: string | null;
+                                email: string | null;
+                            }[];
+                            /** @description True when the activity is open AND has at least one requested reviewer who has not yet responded. Always false for issues. */
+                            awaitingReview: boolean;
+                            reviewRequestedAt: string | null;
+                            /** @description Review lifecycle bucket, or null for issues — an issue is not under review, so no bucket applies. Pass ?viewer to split 'open-awaiting-my-review' from 'open-awaiting-other-review'; without it, a pending review always reads as 'open-awaiting-other-review'. */
+                            reviewStatus: ("draft" | "open-no-review" | "open-awaiting-my-review" | "open-awaiting-other-review" | "open-changes-requested" | "open-approved" | "merged" | "closed") | null;
                             authorIdentity?: {
                                 id: string | number;
                                 displayName: string;
@@ -3857,6 +3905,20 @@ export interface operations {
                             createdAt: string;
                             updatedAt: string;
                             mergedAt: string | null;
+                            /** @description Provider-side logins requested as reviewers (GH `requested_reviewers`, GL `reviewers`). Always empty for issues. GitLab usernames may be numeric strings — those are usernames like any other, not ids. Same field and semantic as LinkedActivity.requestedReviewers, so an activity carries it whether or not it is linked to an issue. */
+                            requestedReviewers: string[];
+                            /** @description Resolved form of `requestedReviewers` (id + login + name + email). Subset: only the logins the GitLab user cache could resolve. Fall back to the raw login from `requestedReviewers` for the rest. */
+                            requestedReviewersResolved?: {
+                                id: string;
+                                login: string;
+                                name: string | null;
+                                email: string | null;
+                            }[];
+                            /** @description True when the activity is open AND has at least one requested reviewer who has not yet responded. Always false for issues. */
+                            awaitingReview: boolean;
+                            reviewRequestedAt: string | null;
+                            /** @description Review lifecycle bucket, or null for issues — an issue is not under review, so no bucket applies. Pass ?viewer to split 'open-awaiting-my-review' from 'open-awaiting-other-review'; without it, a pending review always reads as 'open-awaiting-other-review'. */
+                            reviewStatus: ("draft" | "open-no-review" | "open-awaiting-my-review" | "open-awaiting-other-review" | "open-changes-requested" | "open-approved" | "merged" | "closed") | null;
                             authorIdentity?: {
                                 id: string | number;
                                 displayName: string;
@@ -3887,6 +3949,20 @@ export interface operations {
                             createdAt: string;
                             updatedAt: string;
                             mergedAt: string | null;
+                            /** @description Provider-side logins requested as reviewers (GH `requested_reviewers`, GL `reviewers`). Always empty for issues. GitLab usernames may be numeric strings — those are usernames like any other, not ids. Same field and semantic as LinkedActivity.requestedReviewers, so an activity carries it whether or not it is linked to an issue. */
+                            requestedReviewers: string[];
+                            /** @description Resolved form of `requestedReviewers` (id + login + name + email). Subset: only the logins the GitLab user cache could resolve. Fall back to the raw login from `requestedReviewers` for the rest. */
+                            requestedReviewersResolved?: {
+                                id: string;
+                                login: string;
+                                name: string | null;
+                                email: string | null;
+                            }[];
+                            /** @description True when the activity is open AND has at least one requested reviewer who has not yet responded. Always false for issues. */
+                            awaitingReview: boolean;
+                            reviewRequestedAt: string | null;
+                            /** @description Review lifecycle bucket, or null for issues — an issue is not under review, so no bucket applies. Pass ?viewer to split 'open-awaiting-my-review' from 'open-awaiting-other-review'; without it, a pending review always reads as 'open-awaiting-other-review'. */
+                            reviewStatus: ("draft" | "open-no-review" | "open-awaiting-my-review" | "open-awaiting-other-review" | "open-changes-requested" | "open-approved" | "merged" | "closed") | null;
                             authorIdentity?: {
                                 id: string | number;
                                 displayName: string;

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@cesar-richard/git-connector-sdk",
-  "version": "2.7.0",
+  "version": "2.8.0",
   "description": "TypeScript SDK for the git-connector v1 API (work items + iterations aggregated from GitHub/GitLab). Version published on npm tracks server releases.",
   "license": "MIT",
   "repository": {