@remit/api-openapi-types 0.0.56 → 0.0.57

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@remit/api-openapi-types",
-  "version": "0.0.56",
+  "version": "0.0.57",
   "type": "module",
   "main": "types.d.ts",
   "types": "types.d.ts",

package/types.d.ts

@@ -6544,6 +6544,7 @@ declare namespace Paths {
       from?: string;
       subject?: string;
       accountId?: Components.Schemas.UUID;
+      mailboxId?: Components.Schemas.UUID;
       muted?: boolean;
       category?: Components.Schemas.MessageCategory[];
       unread?: boolean;
@@ -7324,6 +7325,8 @@ Field filters: `from` and `subject` each match one field, which the single `quer
 
 Account scope: `accountId` narrows every mode to the mailboxes of one account. The scope is built from the account's own mailboxes, so the listing, the count and the search all answer over the same set. Without it the listing is the cross-account aggregate.
 
+Folder scope: `mailboxId` narrows the same scope to one folder, and composes with `accountId` as a further AND — a folder of another account leaves the scope empty and matches nothing. It is how a caller asks what one folder holds of a cross-account search, counted in the same conversations the unscoped listing renders. A folder the scope already excludes — Trash, a muted one, one of a muted account — stays excluded.
+
 Muted senders: `muted=false` excludes rows whose From address is muted, `muted=true` returns only those, and omitting it filters nothing. Muting is a property of the address rather than a column on the row, so this is the one predicate that reaches outside the ThreadMessage table; it applies to the listing and the `count` alike, which is what lets a caller that hides muted mail state a number that is the size of what it renders.
 
 Counting: `count=true` answers how many CONVERSATIONS match, over the whole scope and independent of `limit`. `results=false` omits the rows, which is how a header total is read without also paying for a page of mail. Conversations rather than rows because that is what this listing renders: a row is per mailbox, so the same mail filed in two folders is two rows sharing a `threadId`, and clients collapse by it. Counting rows would put a third number beside a list that shows a second one.
@@ -8158,6 +8161,8 @@ Field filters: `from` and `subject` each match one field, which the single `quer
 
 Account scope: `accountId` narrows every mode to the mailboxes of one account. The scope is built from the account's own mailboxes, so the listing, the count and the search all answer over the same set. Without it the listing is the cross-account aggregate.
 
+Folder scope: `mailboxId` narrows the same scope to one folder, and composes with `accountId` as a further AND — a folder of another account leaves the scope empty and matches nothing. It is how a caller asks what one folder holds of a cross-account search, counted in the same conversations the unscoped listing renders. A folder the scope already excludes — Trash, a muted one, one of a muted account — stays excluded.
+
 Muted senders: `muted=false` excludes rows whose From address is muted, `muted=true` returns only those, and omitting it filters nothing. Muting is a property of the address rather than a column on the row, so this is the one predicate that reaches outside the ThreadMessage table; it applies to the listing and the `count` alike, which is what lets a caller that hides muted mail state a number that is the size of what it renders.
 
 Counting: `count=true` answers how many CONVERSATIONS match, over the whole scope and independent of `limit`. `results=false` omits the rows, which is how a header total is read without also paying for a page of mail. Conversations rather than rows because that is what this listing renders: a row is per mailbox, so the same mail filed in two folders is two rows sharing a `threadId`, and clients collapse by it. Counting rows would put a third number beside a list that shows a second one.