/** * Grants access to a calendar. Destructive under the rubric's * standing-side-effect cluster (the `create_filter` and * `sheets/add_protected_range` precedents): the grant keeps conferring access * until something revokes it, so it is not merely additive, and `owner` hands * the scope control of this calendar's sharing. * * Open-world on the precedent of the sends (`gmail/send_message`, * `gmail/send_draft`), because `sendNotifications` defaults to true at Google, so a * grant can send sharing notifications, potentially outside the * organization entirely. Pass `sendNotifications: false` to grant silently. * * A rule's id derives from its scope, so granting a scope that already has a * rule replaces that rule's role rather than adding a second one, and does not * conflict. Verified against the live API rather than inferred: a second * insert for the same scope returned the same rule id with the new role, and * the calendar was left with one rule for that scope. */ export declare const add_acl_rule: import("../../../lib/operation.js").Operation; scope: import("zod").ZodDiscriminatedUnion<[import("zod").ZodObject<{ type: import("zod").ZodLiteral<"default">; }, import("zod/v4/core").$strict>, import("zod").ZodObject<{ type: import("zod").ZodEnum<{ domain: "domain"; group: "group"; user: "user"; }>; value: import("zod").ZodString; }, import("zod/v4/core").$strict>], "type">; calendarId: import("zod").ZodOptional; sendNotifications: import("zod").ZodOptional; }, import("zod/v4/core").$strict>, import("zod").ZodObject<{ id: import("zod").ZodString; role: import("zod").ZodOptional>; scope: import("zod").ZodOptional; }, import("zod/v4/core").$strict>, import("zod").ZodObject<{ type: import("zod").ZodEnum<{ domain: "domain"; group: "group"; user: "user"; }>; value: import("zod").ZodString; }, import("zod/v4/core").$strict>], "type">>; }, import("zod/v4/core").$strip>>; //# sourceMappingURL=index.d.ts.map