Module write_gate 

Folder-scoped write-permission gate (issue #1574).

omni-dev’s own local policy layer bounding drive create/upload/ edit, independent of and enforced in addition to whatever the OAuth scope (crate::drive::auth::DriveGrantedScopes) would technically allow. Google’s Drive scopes are all-or-nothing across a user’s whole Drive — there is no Google-side way to say “this credential may only write inside folder X” — so this module fills that gap.

Deliberately pure: zero DriveClient/network dependency, mirroring crate::drive::visibility’s contract exactly. Fetching the ancestor folder chain a target lives in is crate::drive::folder_ancestry’s job; this module only classifies an already-resolved chain.

Named write_gate, not permission(s), to avoid any confusion with crate::drive::permissions_api — Google’s own sharing/ACL wrapper, a completely unrelated concept.

The algorithm

A target (the --parent folder for create/upload, or a file’s current parent folder(s) for edit) is identified by its ancestor chain: chain[0] is the target folder itself, chain[1] its parent, chain[2] its grandparent, and so on up to Drive’s root. resolve walks that chain looking for the closest (lowest-depth) rule naming any folder in it — a non-recursive rule only ever matches at depth 0, its own folder; a recursive rule matches at any depth. Two tie-breaks, both security-relevant and each covered by a dedicated test:

• Closest ancestor wins: a rule on a subfolder overrides a broader rule on its parent — the more specific grant/restriction is assumed the more deliberate one.
• Deny beats allow at equal depth: if two rules at the same depth disagree, the safe direction wins.

When no rule anywhere in the chain names op, DriveOperation::default_policy decides it: Read defaults to Verdict::Allow, every write operation defaults to Verdict::Deny. This is where “disabled by default” for writes actually lives — there is deliberately no separate enabled/ disabled toggle; an absent or empty rule list already means “deny everywhere” via this table alone.

Structs

DecidingRule

Which configured rule (if any) decided a Decision.

Decision

The outcome of resolve: whether an operation is permitted, and which rule (if any) decided it.

FolderPermissionRule

One configured folder rule.

Enums

DriveOperation

A Drive operation this gate can permit or refuse. Reused directly as the settings-file rule shape (crate::utils::settings::WritePermissionsSettings) — no separate wire type.

Verdict

The result of resolving a single operation against a rule set.

Functions

combine_across_parents

Combines per-parent Decisions into one, for a target with more than one current parent (a legacy multi-parent file — Drive no longer permits creating new ones).

decided_by_log_fields

Splits an optional DecidingRule into the (folder_id, depth) pair crate::request_log::DriveMutationOutcome::decided_by_folder_id/ decided_by_depth expect.

resolve

Resolves whether op is permitted against chain (depth 0 = the target folder itself, then parent, grandparent, …) under rules. See the module doc for the full algorithm and its tie-breaks.