@oneuptime/common 12.0.17 → 12.0.19

package/Tests/Server/Types/Database/Permissions/AdminNotificationRuleAccess.test.ts

@@ -1,7 +1,9 @@
 import UserCall from "../../../../../Models/DatabaseModels/UserCall";
 import UserEmail from "../../../../../Models/DatabaseModels/UserEmail";
+import UserMicrosoftTeams from "../../../../../Models/DatabaseModels/UserMicrosoftTeams";
 import UserNotificationRule from "../../../../../Models/DatabaseModels/UserNotificationRule";
 import UserPush from "../../../../../Models/DatabaseModels/UserPush";
+import UserSlack from "../../../../../Models/DatabaseModels/UserSlack";
 import UserSMS from "../../../../../Models/DatabaseModels/UserSMS";
 import UserTelegram from "../../../../../Models/DatabaseModels/UserTelegram";
 import UserWebhook from "../../../../../Models/DatabaseModels/UserWebhook";
@@ -38,12 +40,13 @@ import { describe, expect, test } from "@jest/globals";
  * decide it: a member with no matching rule was silently unpageable, and the
  * only person able to notice was the person who was not being notified.
  *
- * PHASE 3 SHIPPED THAT CAPABILITY ON THE RULE TABLE AND ONLY THERE. The seven
+ * PHASE 3 SHIPPED THAT CAPABILITY ON THE RULE TABLE AND ONLY THERE. The nine
  * notification-method models - UserEmail, UserSMS, UserCall, UserPush,
- * UserWhatsApp, UserTelegram, UserWebhook - stay CurrentUser-only on every
- * verb, so an administrator reading one of THEM is refused exactly like any
- * other member. That split is not a leftover; it is the design, and it is the
- * design because the alternative was tried and did not hold.
+ * UserWhatsApp, UserTelegram, UserSlack, UserMicrosoftTeams, UserWebhook -
+ * stay CurrentUser-only on every verb, so an administrator reading one of THEM
+ * is refused exactly like any other member. That split is not a leftover; it
+ * is the design, and it is the design because the alternative was tried and
+ * did not hold.
  *
  * WHY THE METHOD TABLES COULD NOT BE WIDENED. Widening a read on a model that
  * scopes rows by owner is a privilege change rather than a convenience change,
@@ -77,7 +80,7 @@ import { describe, expect, test } from "@jest/globals";
  *
  *   - the rule table lifts for an administrator and not for a plain member, on
  *     all four verbs;
- *   - the seven method models lift for NOBODY on ANY verb, and the read case is
+ *   - the nine method models lift for NOBODY on ANY verb, and the read case is
  *     asserted in both directions because it is the one that shipped widened
  *     once already;
  *   - the rule's method FK id columns are admin-readable while the method
@@ -147,9 +150,9 @@ const NEW_GRANULAR_PERMISSIONS: Array<Permission> = [
 ];
 
 /*
- * The seven notification methods a rule can point at. Every method assertion
- * runs against all seven rather than against a representative one: they are
- * seven copies of one decorator shape, and a widening applied to one of them is
+ * The nine notification methods a rule can point at. Every method assertion
+ * runs against all nine rather than against a representative one: they are
+ * nine copies of one decorator shape, and a widening applied to one of them is
  * exactly the kind of thing that survives review.
  */
 const METHOD_MODELS: Array<[string, ModelConstructor]> = [
@@ -159,6 +162,8 @@ const METHOD_MODELS: Array<[string, ModelConstructor]> = [
   ["UserPush", UserPush],
   ["UserWhatsApp", UserWhatsApp],
   ["UserTelegram", UserTelegram],
+  ["UserSlack", UserSlack],
+  ["UserMicrosoftTeams", UserMicrosoftTeams],
   ["UserWebhook", UserWebhook],
 ];
 
@@ -478,10 +483,10 @@ describe("the rule table - an administrator's row scope lifts, a member's does n
   });
 });
 
-describe("the seven methods - an administrator may not look either", () => {
+describe("the nine methods - an administrator may not look either", () => {
   /*
    * THE CORE DECISION OF THIS PHASE AS IT FINALLY SHIPPED, AND THE ONE MOST
-   * LIKELY TO BE "TIDIED UP" LATER, because seven models that differ from their
+   * LIKELY TO BE "TIDIED UP" LATER, because nine models that differ from their
    * sibling in all four lists look like an oversight rather than a decision.
    *
    * The read half of these lists was widened once and then reverted. The reason
@@ -1243,7 +1248,7 @@ describe("the credentials behind a notification method, guarded by the table sco
    * column-level decision to verify per column and per query shape, because
    * there is no query on these models that reaches another member's ROW - so
    * every column on that row, credential or label, is out of reach for the same
-   * single reason. The five columns are still enumerated rather than reduced to
+   * single reason. The columns are still enumerated rather than reduced to
    * one representative, because they are what a reader comes here looking for
    * and because "the row is unreachable" is a claim worth checking against the
    * things that would actually matter if it were false.
@@ -1251,8 +1256,10 @@ describe("the credentials behind a notification method, guarded by the table sco
    * The columns: the webhook URL and its signing secret (both bearer
    * credentials - anyone holding them can impersonate OneUptime to the member's
    * endpoint), the push device token, the Telegram chat id an unverified bot
-   * message can be addressed to, and the verification code that turns
-   * possession of that chat id into a verified method.
+   * message can be addressed to, the verification code that turns possession
+   * of that chat id into a verified method, and the Slack member id and
+   * Microsoft Teams user id the project's workspace bots deliver direct
+   * messages to.
    */
 
   /*
@@ -1266,6 +1273,8 @@ describe("the credentials behind a notification method, guarded by the table sco
     ["UserPush", "deviceToken", UserPush],
     ["UserTelegram", "telegramChatId", UserTelegram],
     ["UserTelegram", "verificationCode", UserTelegram],
+    ["UserSlack", "slackUserId", UserSlack],
+    ["UserMicrosoftTeams", "microsoftTeamsUserId", UserMicrosoftTeams],
   ];
 
   test.each(CREDENTIAL_COLUMNS)(
@@ -1375,8 +1384,8 @@ describe("the rule relation - an administrator reads the FK, never the method be
    *
    * Neither check can see the query, so neither can tell whose row this is.
    * That leaves the outer column list as the only place the decision can be
-   * made, and it is why the seven method RELATION columns on
-   * UserNotificationRule are `read: [Permission.CurrentUser]` while the seven
+   * made, and it is why the nine method RELATION columns on
+   * UserNotificationRule are `read: [Permission.CurrentUser]` while the nine
    * FK ID columns beside them are admin-readable. The pairing is the design in
    * one line: an administrator may learn WHICH method a rule points at, and may
    * re-point it at a different one, without ever learning what the method IS.
@@ -1397,6 +1406,8 @@ describe("the rule relation - an administrator reads the FK, never the method be
     "userPushId",
     "userWhatsAppId",
     "userTelegramId",
+    "userSlackId",
+    "userMicrosoftTeamsId",
     "userWebhookId",
   ];
 
@@ -1412,6 +1423,8 @@ describe("the rule relation - an administrator reads the FK, never the method be
     ["userPush", "deviceToken"],
     ["userWhatsApp", "phone"],
     ["userTelegram", "telegramChatId"],
+    ["userSlack", "slackUserId"],
+    ["userMicrosoftTeams", "microsoftTeamsUserId"],
     ["userWebhook", "webhookUrl"],
   ];
 
@@ -1420,7 +1433,7 @@ describe("the rule relation - an administrator reads the FK, never the method be
     async (grant: Permission): Promise<void> => {
       /*
        * The capability half, and it has to pass or the refusal below has taken
-       * the feature with it. Selecting all seven ids at once rather than one
+       * the feature with it. Selecting all nine ids at once rather than one
        * representative, because the admin surface renders the whole row and a
        * single narrowed column would break the page while six tests still
        * passed.

package/Tests/Server/Types/Database/Permissions/CreateOwnershipScoping.test.ts

@@ -4,12 +4,14 @@ import User from "../../../../../Models/DatabaseModels/User";
 import UserCall from "../../../../../Models/DatabaseModels/UserCall";
 import UserEmail from "../../../../../Models/DatabaseModels/UserEmail";
 import UserIncomingCallNumber from "../../../../../Models/DatabaseModels/UserIncomingCallNumber";
+import UserMicrosoftTeams from "../../../../../Models/DatabaseModels/UserMicrosoftTeams";
 import UserNotificationRule from "../../../../../Models/DatabaseModels/UserNotificationRule";
 import UserNotificationSetting from "../../../../../Models/DatabaseModels/UserNotificationSetting";
 import UserOnCallLog from "../../../../../Models/DatabaseModels/UserOnCallLog";
 import UserPush from "../../../../../Models/DatabaseModels/UserPush";
 import UserSMS from "../../../../../Models/DatabaseModels/UserSMS";
 import UserSession from "../../../../../Models/DatabaseModels/UserSession";
+import UserSlack from "../../../../../Models/DatabaseModels/UserSlack";
 import UserTelegram from "../../../../../Models/DatabaseModels/UserTelegram";
 import UserTotpAuth from "../../../../../Models/DatabaseModels/UserTotpAuth";
 import UserWebAuthn from "../../../../../Models/DatabaseModels/UserWebAuthn";
@@ -42,8 +44,8 @@ import { describe, expect, test } from "@jest/globals";
  * allow-list intersection over column names. So on any model whose create list
  * is CurrentUser-only, a caller could write a row owned by somebody else.
  *
- * Fourteen models have that shape, and every one of them is a "my own X"
- * resource: notification rules, all seven notification methods behind them,
+ * Sixteen models have that shape, and every one of them is a "my own X"
+ * resource: notification rules, all nine notification methods behind them,
  * sessions, TOTP and WebAuthn credentials, workspace tokens. On the
  * notification models the ownership column is not bookkeeping — it decides
  * whose on-call pages select the row, while the address actually messaged is
@@ -124,7 +126,8 @@ type ModelConstructor = { new (): BaseModel };
  * Every model whose create list is exactly [Permission.CurrentUser]. These are
  * the ones the fix protects, and the ones an attacker could previously write on
  * another user's behalf. Enumerated rather than discovered so that adding a
- * fifteenth model with this shape is a deliberate act that shows up in review.
+ * seventeenth model with this shape is a deliberate act that shows up in
+ * review.
  */
 const CURRENT_USER_ONLY_MODELS: Array<[string, ModelConstructor]> = [
   ["UserNotificationRule", UserNotificationRule],
@@ -135,6 +138,8 @@ const CURRENT_USER_ONLY_MODELS: Array<[string, ModelConstructor]> = [
   ["UserPush", UserPush],
   ["UserWhatsApp", UserWhatsApp],
   ["UserTelegram", UserTelegram],
+  ["UserSlack", UserSlack],
+  ["UserMicrosoftTeams", UserMicrosoftTeams],
   ["UserNotificationSetting", UserNotificationSetting],
   ["UserIncomingCallNumber", UserIncomingCallNumber],
   ["UserSession", UserSession],

package/Tests/Server/Types/Database/Permissions/OwnerOnlyColumns.test.ts

@@ -1,6 +1,8 @@
 import UserCall from "../../../../../Models/DatabaseModels/UserCall";
 import UserEmail from "../../../../../Models/DatabaseModels/UserEmail";
+import UserMicrosoftTeams from "../../../../../Models/DatabaseModels/UserMicrosoftTeams";
 import UserPush from "../../../../../Models/DatabaseModels/UserPush";
+import UserSlack from "../../../../../Models/DatabaseModels/UserSlack";
 import UserSMS from "../../../../../Models/DatabaseModels/UserSMS";
 import UserTelegram from "../../../../../Models/DatabaseModels/UserTelegram";
 import UserWebhook from "../../../../../Models/DatabaseModels/UserWebhook";
@@ -34,7 +36,7 @@ import UserType from "../../../../../Types/UserType";
  * administrators - which is the feature, and is correct - and the moment it
  * does, an admin's read of that table is no longer confined to their own rows.
  * Everything reachable from those rows is then reachable by an admin, and the
- * seven notification-method models hang off them by ManyToOne relation.
+ * nine notification-method models hang off them by ManyToOne relation.
  *
  * There are FOUR routes into a marked column, and closing three of them is the
  * same as closing none. Every route below is driven through the real permission
@@ -49,7 +51,7 @@ import UserType from "../../../../../Types/UserType";
  *   Route 3  sort:   { webhookUrl: "ASC" }                      injected post-gate
  *   Route 4  query:  { webhookUrl: "https://..." }              as a value oracle
  *
- * HOW THE ADMIN CASE IS SET UP, AND WHY IT IS NOT THEATRE. Today the seven
+ * HOW THE ADMIN CASE IS SET UP, AND WHY IT IS NOT THEATRE. Today the nine
  * method models list [CurrentUser] and nothing else, so TenantPermission stamps
  * every non-root caller's own userId onto their query and an administrator is
  * indistinguishable from a plain member - the admin case is currently
@@ -68,7 +70,7 @@ const otherUserId: ObjectID = ObjectID.generate();
 type ModelTypeUnderTest = { new (): BaseModel };
 
 /*
- * The seven notification-method models with the post-Phase-3 table read. Only
+ * The nine notification-method models with the post-Phase-3 table read. Only
  * the table access control is restated; every column, its @OwnerOnlyColumn
  * mark, the tenant column and @CurrentUserCanAccessRecordBy("userId") are
  * inherited from the production model.
@@ -103,6 +105,12 @@ class AdminReadableUserWhatsApp extends UserWhatsApp {}
 @TableAccessControl(ADMIN_READABLE_TABLE_ACCESS)
 class AdminReadableUserTelegram extends UserTelegram {}
 
+@TableAccessControl(ADMIN_READABLE_TABLE_ACCESS)
+class AdminReadableUserSlack extends UserSlack {}
+
+@TableAccessControl(ADMIN_READABLE_TABLE_ACCESS)
+class AdminReadableUserMicrosoftTeams extends UserMicrosoftTeams {}
+
 @TableAccessControl(ADMIN_READABLE_TABLE_ACCESS)
 class AdminReadableUserWebhook extends UserWebhook {}
 
@@ -218,6 +226,32 @@ class AdminReadableRuleModel extends BaseModel {
   })
   public userTelegram?: UserTelegram = undefined;
 
+  @ColumnAccessControl({
+    create: [Permission.CurrentUser],
+    read: [Permission.CurrentUser, Permission.ProjectAdmin],
+    update: [],
+  })
+  @TableColumn({
+    type: TableColumnType.Entity,
+    modelType: UserSlack,
+    manyToOneRelationColumn: "userSlackId",
+    title: "User Slack",
+  })
+  public userSlack?: UserSlack = undefined;
+
+  @ColumnAccessControl({
+    create: [Permission.CurrentUser],
+    read: [Permission.CurrentUser, Permission.ProjectAdmin],
+    update: [],
+  })
+  @TableColumn({
+    type: TableColumnType.Entity,
+    modelType: UserMicrosoftTeams,
+    manyToOneRelationColumn: "userMicrosoftTeamsId",
+    title: "User Microsoft Teams",
+  })
+  public userMicrosoftTeams?: UserMicrosoftTeams = undefined;
+
   @ColumnAccessControl({
     create: [Permission.CurrentUser],
     read: [Permission.CurrentUser, Permission.ProjectAdmin],
@@ -359,6 +393,41 @@ const METHOD_MODELS: Array<MethodModelUnderTest> = [
     labelColumns: ["userId", "projectId", "isVerified"],
     unmarkedSortColumn: "isVerified",
   },
+  {
+    name: "UserSlack",
+    modelType: UserSlack,
+    adminReadableModelType: AdminReadableUserSlack,
+    relationColumnName: "userSlack",
+    /*
+     * No verificationCode here: a Slack row is born verified off the user's own
+     * OAuth workspace link, so the two marked columns are the member id the bot
+     * delivers to and the display name that identifies the person in an outside
+     * workspace. Both are owner-readable, so the owner-only mark is the ONLY
+     * thing between them and any admin in the project.
+     */
+    ownerOnlyColumns: ["slackUserId", "slackUserName"],
+    ownerOnlyColumnsSelectableByOwner: ["slackUserId", "slackUserName"],
+    ownerOnlyColumnReachableThroughRelation: "slackUserId",
+    labelColumnReachableThroughRelation: "projectId",
+    labelColumns: ["userId", "projectId", "isVerified"],
+    unmarkedSortColumn: "isVerified",
+  },
+  {
+    name: "UserMicrosoftTeams",
+    modelType: UserMicrosoftTeams,
+    adminReadableModelType: AdminReadableUserMicrosoftTeams,
+    relationColumnName: "userMicrosoftTeams",
+    // Same shape as UserSlack: created verified, no verificationCode column.
+    ownerOnlyColumns: ["microsoftTeamsUserId", "microsoftTeamsUserName"],
+    ownerOnlyColumnsSelectableByOwner: [
+      "microsoftTeamsUserId",
+      "microsoftTeamsUserName",
+    ],
+    ownerOnlyColumnReachableThroughRelation: "microsoftTeamsUserId",
+    labelColumnReachableThroughRelation: "projectId",
+    labelColumns: ["userId", "projectId", "isVerified"],
+    unmarkedSortColumn: "isVerified",
+  },
   {
     name: "UserWebhook",
     modelType: UserWebhook,

package/Tests/Server/Types/Database/Permissions/UserNotificationRuleScoping.test.ts

@@ -1,8 +1,10 @@
 import TeamMember from "../../../../../Models/DatabaseModels/TeamMember";
 import UserCall from "../../../../../Models/DatabaseModels/UserCall";
 import UserEmail from "../../../../../Models/DatabaseModels/UserEmail";
+import UserMicrosoftTeams from "../../../../../Models/DatabaseModels/UserMicrosoftTeams";
 import UserNotificationRule from "../../../../../Models/DatabaseModels/UserNotificationRule";
 import UserPush from "../../../../../Models/DatabaseModels/UserPush";
+import UserSlack from "../../../../../Models/DatabaseModels/UserSlack";
 import UserSMS from "../../../../../Models/DatabaseModels/UserSMS";
 import UserTelegram from "../../../../../Models/DatabaseModels/UserTelegram";
 import UserWebhook from "../../../../../Models/DatabaseModels/UserWebhook";
@@ -27,8 +29,8 @@ import Permission from "../../../../../Types/Permission";
  * WHAT THIS FILE PINS
  *
  * On-call notification configuration - the rules themselves plus every channel
- * they can fire through (email, SMS, call, push, WhatsApp, Telegram, webhook) -
- * is row-scoped to its owner by one mechanism:
+ * they can fire through (email, SMS, call, push, WhatsApp, Telegram, Slack,
+ * Microsoft Teams, webhook) - is row-scoped to its owner by one mechanism:
  *
  *   @TableAccessControl({ ... [Permission.CurrentUser] ... })
  *   @CurrentUserCanAccessRecordBy("userId")
@@ -39,7 +41,7 @@ import Permission from "../../../../../Types/Permission";
  * addCurrentUserScopeToQuery() rewrites the query to `userId = me`, and throws
  * NotAuthorizedException outright if the caller had explicitly named somebody
  * else. The FIRST group below is the standing proof that this still holds for a
- * plain member on all eight models.
+ * plain member on all ten models.
  *
  * GAP D in Internal/Roadmap/OnCallNotificationReadiness.md was the consequence
  * for everybody else: a Project ADMIN was treated identically to a plain member
@@ -55,12 +57,12 @@ import Permission from "../../../../../Types/Permission";
  *     a member's rules, repair them, delete them, and provision one for a
  *     member who has none.
  *
- *   - The SEVEN METHOD MODELS widen on NOTHING. All four lists are
+ *   - The NINE METHOD MODELS widen on NOTHING. All four lists are
  *     [CurrentUser], so an administrator is force-scoped onto their own rows
  *     there and is rejected outright for naming somebody else, on every verb -
  *     indistinguishable from a plain member.
  *
- * The read half of those seven WAS widened at one point, and reverting it is
+ * The read half of those models WAS widened at one point, and reverting it is
  * the most load-bearing fact in this file. The table scope is not one gate
  * among several on these models; it is the only one. Every column on them
  * declares `read: [Permission.CurrentUser]`, and that list is intersected by
@@ -97,7 +99,7 @@ import Permission from "../../../../../Types/Permission";
  *     list. It is force-scoped for a member and unscoped for an admin. The
  *     ownership decorator was therefore never the thing scoping admins out -
  *     the absent permission entry was, which is why the rule table's fix is an
- *     entry in a list rather than a new gate, and why the seven methods stay
+ *     entry in a list rather than a new gate, and why the nine methods stay
  *     scoped purely by having no such entry.
  *
  *   - AdminReadableNotificationRuleModel below isolates the same shape on a
@@ -113,7 +115,7 @@ import Permission from "../../../../../Types/Permission";
  * production models, but a combination of verbs that none of them use.
  *
  * It is deliberately not a copy of any shipping model - not of the rule table,
- * whose four lists are all widened, and not of the seven methods, whose four
+ * whose four lists are all widened, and not of the nine methods, whose four
  * lists are all closed. Its job is to pin the mechanism - the scope lifts for
  * the operations whose list names a real permission and holds for the ones
  * whose list does not - so that the production assertions above it are testing
@@ -154,8 +156,8 @@ class AdminReadableNotificationRuleModel extends BaseModel {
 type ModelTypeUnderTest = { new (): BaseModel };
 
 /*
- * The seven channels a rule can fire through. They are seven copies of one
- * decorator shape, so every method assertion runs against all seven rather than
+ * The nine channels a rule can fire through. They are nine copies of one
+ * decorator shape, so every method assertion runs against all nine rather than
  * against a representative one - a widening applied to one of them is exactly
  * the kind of thing that survives review.
  */
@@ -166,16 +168,18 @@ const NOTIFICATION_METHOD_MODELS: Array<ModelTypeUnderTest> = [
   UserPush,
   UserWhatsApp,
   UserTelegram,
+  UserSlack,
+  UserMicrosoftTeams,
   UserWebhook,
 ];
 
 /*
  * Every model that makes up a user's on-call notification configuration.
  *
- * All eight behave identically for a plain member, which is what the first
+ * All ten behave identically for a plain member, which is what the first
  * group asserts over this list. They diverge only in what an ADMINISTRATOR
  * sees, so the admin-facing groups below name UserNotificationRule separately
- * and iterate NOTIFICATION_METHOD_MODELS for the seven that stay closed.
+ * and iterate NOTIFICATION_METHOD_MODELS for the nine that stay closed.
  */
 const NOTIFICATION_CONFIG_MODELS: Array<ModelTypeUnderTest> = [
   UserNotificationRule,
@@ -194,7 +198,7 @@ const ROW_SCOPED_REQUEST_TYPES: Array<DatabaseRequestType> = [
  * the model equals itself; naming them independently means a change to a
  * shipping list has to be re-stated deliberately in a test.
  *
- * On the seven method models these names appear only inside a `not.toContain`.
+ * On the nine method models these names appear only inside a `not.toContain`.
  */
 const ADMIN_READ_GRANTS: Array<Permission> = [
   Permission.ProjectOwner,
@@ -554,10 +558,10 @@ describe("GAP D closed - the rule table opens to a ProjectAdmin on every verb",
   });
 });
 
-describe("GAP D closed on the rule table alone - the seven methods open to nobody", () => {
+describe("GAP D closed on the rule table alone - the nine methods open to nobody", () => {
   /*
    * THE BOUNDARY OF THE PHASE, AND THE PART MOST LIKELY TO BE "TIDIED UP"
-   * LATER, because seven models that differ from their sibling in all four
+   * LATER, because nine models that differ from their sibling in all four
    * lists look like an oversight rather than a decision.
    *
    * Two independent reasons keep them closed, and both have to be understood or
@@ -736,7 +740,7 @@ describe("TeamMember proves the mechanism - a listed admin permission lifts the
      *
      * That is the whole of what the rule table gained, on a model that has
      * always shipped it - which is why the fix there was an entry in a list
-     * rather than a new gate, and equally why the seven method models stay
+     * rather than a new gate, and equally why the nine method models stay
      * closed by simply having no such entry. Nothing guards them beyond the
      * absence, so this group stays here as the independent statement of what
      * the absence is doing.
@@ -842,14 +846,14 @@ describe("TeamMember proves the mechanism - a listed admin permission lifts the
 
 describe("the lift mechanism in isolation, on a throwaway model", () => {
   /*
-   * The production groups above assert what UserNotificationRule and the seven
+   * The production groups above assert what UserNotificationRule and the nine
    * methods DO; this group asserts what the framework does with any user-scoped
    * model, on a class whose lists match neither of them - all four widened on
    * the rule table, all four closed on the methods, two-of-four here.
    *
    * That mismatch is the point. If a future change to TenantPermission alters
    * the rule, this group fails on its own terms and says so, instead of the
-   * failure arriving disguised as eight models having drifted.
+   * failure arriving disguised as ten models having drifted.
    */
 
   it("lifts the ownership scope for a ProjectAdmin on read and update", async () => {
@@ -989,7 +993,7 @@ describe("notification config model decorators", () => {
        * while "restoring the admin feature" - and re-adding it silently removes
        * the row scope that every column on the model depends on. Neither
        * ADMIN_READ_GRANTS nor ADMIN_WRITE_GRANTS belongs in any list on these
-       * seven; there is no verb on a notification method that an administrator
+       * nine; there is no verb on a notification method that an administrator
        * may perform on somebody else's row.
        */
       const model: BaseModel = new modelType();

package/Tests/Server/Types/Database/Permissions/WorkspaceMethodStampedColumnCreate.test.ts

@@ -0,0 +1,178 @@
+import DatabaseRequestType from "../../../../../Server/Types/BaseDatabase/DatabaseRequestType";
+import ColumnPermissions from "../../../../../Server/Types/Database/Permissions/ColumnPermission";
+import UserSlack from "../../../../../Models/DatabaseModels/UserSlack";
+import UserMicrosoftTeams from "../../../../../Models/DatabaseModels/UserMicrosoftTeams";
+import DatabaseCommonInteractionProps from "../../../../../Types/BaseDatabase/DatabaseCommonInteractionProps";
+import ObjectID from "../../../../../Types/ObjectID";
+import Permission, {
+  UserTenantAccessPermission,
+} from "../../../../../Types/Permission";
+import { describe, expect, it } from "@jest/globals";
+
+/*
+ * REGRESSION PIN for the defect that made the whole feature dead on arrival.
+ *
+ * UserSlackService / UserMicrosoftTeamsService stamp the workspace identifier,
+ * the display name and isVerified onto createBy.data inside onBeforeCreate.
+ * DatabaseService.create runs that hook FIRST and only then calls
+ * ModelPermission.checkCreatePermissions on the STAMPED data — so the column
+ * ACLs are evaluated against values the SERVER wrote, with the CALLER's
+ * permissions. When those three columns carried `create: []`, every non-root
+ * create was refused with "User is not allowed to create on slackUserId
+ * column of Slack Account": no user could ever add Slack or Microsoft Teams
+ * as a notification method through the API or the dashboard, and no test
+ * noticed because the service suites call the hook directly rather than
+ * DatabaseService.create.
+ *
+ * The columns therefore carry `create: [Permission.CurrentUser]` — the same
+ * shape UserWebAuthn uses for its server-stamped isVerified — and the thing
+ * that keeps the values out of the CLIENT's hands is the hook itself, which
+ * refuses any non-root payload carrying them BEFORE it stamps. These tests
+ * pin both halves: the stamped shape passes the column check, and the check
+ * itself is really being evaluated (the harness guard).
+ */
+
+const projectId: ObjectID = ObjectID.generate();
+const userId: ObjectID = ObjectID.generate();
+
+function makeProps(
+  permissions: Array<Permission>,
+): DatabaseCommonInteractionProps {
+  const tenantPermission: UserTenantAccessPermission = {
+    projectId,
+    _type: "UserTenantAccessPermission",
+    permissions: permissions.map((permission: Permission) => {
+      return {
+        _type: "UserPermission",
+        permission: permission,
+        labelIds: [],
+        isBlockPermission: false,
+      };
+    }),
+  };
+
+  return {
+    userId,
+    tenantId: projectId,
+    userTenantAccessPermission: {
+      [projectId.toString()]: tenantPermission,
+    },
+  };
+}
+
+/* Exactly what UserSlackService.onBeforeCreate leaves on createBy.data. */
+function stampedUserSlack(): UserSlack {
+  const model: UserSlack = new UserSlack();
+  model.projectId = projectId;
+  model.userId = userId;
+  model.slackUserId = "U0123ABCD";
+  model.slackUserName = "alice";
+  model.isVerified = true;
+  return model;
+}
+
+/* Exactly what UserMicrosoftTeamsService.onBeforeCreate leaves behind. */
+function stampedUserMicrosoftTeams(): UserMicrosoftTeams {
+  const model: UserMicrosoftTeams = new UserMicrosoftTeams();
+  model.projectId = projectId;
+  model.userId = userId;
+  model.microsoftTeamsUserId = "e6f1c1f7-aad0-4b6c-9c11-2f5b7c8d9e0f";
+  model.microsoftTeamsUserName = "Alice Example";
+  model.isVerified = true;
+  return model;
+}
+
+describe("server-stamped workspace method columns survive the create column check", () => {
+  /*
+   * Harness guard: a caller with NO permissions at all must still be refused,
+   * or every "does not throw" below would pass because the permission set was
+   * mis-built rather than because the columns are actually creatable.
+   * CurrentUser is auto-granted to authenticated callers by
+   * getUserPermissions, so the guard uses a column no list opens: userId's
+   * create list contains CurrentUser, but a props object with no userId is
+   * unauthenticated and gets nothing.
+   */
+  it("harness guard: an unauthenticated caller is still refused", () => {
+    const props: DatabaseCommonInteractionProps = makeProps([]);
+    delete (props as { userId?: ObjectID }).userId;
+
+    expect(() => {
+      ColumnPermissions.checkDataColumnPermissions(
+        UserSlack,
+        stampedUserSlack(),
+        props,
+        DatabaseRequestType.Create,
+      );
+    }).toThrow();
+  });
+
+  it("a stamped UserSlack passes for a plain authenticated member", () => {
+    expect(() => {
+      ColumnPermissions.checkDataColumnPermissions(
+        UserSlack,
+        stampedUserSlack(),
+        makeProps([Permission.CurrentUser]),
+        DatabaseRequestType.Create,
+      );
+    }).not.toThrow();
+  });
+
+  it("a stamped UserMicrosoftTeams passes for a plain authenticated member", () => {
+    expect(() => {
+      ColumnPermissions.checkDataColumnPermissions(
+        UserMicrosoftTeams,
+        stampedUserMicrosoftTeams(),
+        makeProps([Permission.CurrentUser]),
+        DatabaseRequestType.Create,
+      );
+    }).not.toThrow();
+  });
+
+  /*
+   * The other half of the design: opening the column ACL did NOT hand the
+   * value to the client — the SERVICE hook refuses any non-root payload that
+   * arrives carrying these columns, before anything is stamped. That refusal
+   * is pinned in UserSlackService.test.ts / UserMicrosoftTeamsService.test.ts
+   * ("cannot be set directly" / "cannot be set to true"); this file exists so
+   * that the two halves cannot drift apart unnoticed: if someone reverts the
+   * ACL to create: [], the two "passes" tests above fail; if someone removes
+   * the hook guards, the service suites fail.
+   */
+  it("update stays closed: even the owner cannot rewrite the stamped identifier", () => {
+    expect(() => {
+      ColumnPermissions.checkDataColumnPermissions(
+        UserSlack,
+        { slackUserId: "U-ATTACKER" } as UserSlack,
+        makeProps([Permission.CurrentUser]),
+        DatabaseRequestType.Update,
+      );
+    }).toThrow();
+  });
+
+  it("update stays closed on the Teams identifier too", () => {
+    expect(() => {
+      ColumnPermissions.checkDataColumnPermissions(
+        UserMicrosoftTeams,
+        { microsoftTeamsUserId: "spoofed" } as UserMicrosoftTeams,
+        makeProps([Permission.CurrentUser]),
+        DatabaseRequestType.Update,
+      );
+    }).toThrow();
+  });
+
+  it("update stays closed on isVerified for both models", () => {
+    for (const [modelType, data] of [
+      [UserSlack, { isVerified: true } as UserSlack],
+      [UserMicrosoftTeams, { isVerified: true } as UserMicrosoftTeams],
+    ] as Array<[{ new (): UserSlack | UserMicrosoftTeams }, UserSlack]>) {
+      expect(() => {
+        ColumnPermissions.checkDataColumnPermissions(
+          modelType,
+          data,
+          makeProps([Permission.CurrentUser]),
+          DatabaseRequestType.Update,
+        );
+      }).toThrow();
+    }
+  });
+});