Struct FolderPermissionRule 

pub struct FolderPermissionRule {
    pub folder_id: Option<String>,
    pub file_id: Option<String>,
    pub recursive: bool,
    pub allow: HashSet<DriveOperation>,
    pub deny: HashSet<DriveOperation>,
    pub require_lease: bool,
}

One configured permission rule, keyed on either a folder id or a file id — exactly one of the two, enforced when the settings file is deserialized (see the private RawPermissionRule below).

Ids are Drive’s own canonical ids, not paths — Drive objects have no stable, unique path (names collide, files can have multiple legacy parents), so identity is the id, exactly as the browser bridge’s OriginAllowlist matches exact origin strings rather than URL patterns.

A file_id rule is what makes a file shared by link or email grantable at all (issue #1612): files.get returns only the parents this account can see, so such a file arrives with none, and no folder rule could ever apply to it.

Fields

folder_id: Option<String>

The Drive folder id this rule matches, for a folder rule.

file_id: Option<String>

The Drive file id this rule matches, for a file rule. Matched at depth −1 against the target itself, before any ancestor walk — see resolve_file_rule.

recursive: bool

When true, this rule also matches every descendant of folder_id, not just the folder itself (depth > 0 in the ancestor chain). A non-recursive rule only ever matches at depth 0. Meaningless — and rejected — on a file_id rule: a file has no descendants.

allow: HashSet<DriveOperation>

Operations explicitly permitted at this target.

deny: HashSet<DriveOperation>

Operations explicitly refused at this target.

require_lease: bool

Whether a content-mutating write matching this rule requires a valid Drive write lease (ADR-0080 §1/§13) in addition to this gate’s own verdict. Defaults to true; an operator sets it to false to relax the requirement for a specific folder, which skips both the backup and the Touch ID prompt (§13) — a rule that skipped only one of the two would either surprise an operator who explicitly relaxed this, or ask for consent to a guarantee it then doesn’t provide. Independent of allow/deny: the lease is orthogonal to this gate, not another operation in its vocabulary.

Implementations

impl FolderPermissionRule

pub fn folder(folder_id: impl Into<String>) -> Self

A folder rule naming folder_id.

pub fn file(file_id: impl Into<String>) -> Self

A file rule naming file_id.

pub fn recursive(self, recursive: bool) -> Self

Sets recursive, for builder-style construction in tests and callers assembling rules programmatically.

pub fn requiring_lease(self, require_lease: bool) -> Self

Sets require_lease, for builder-style construction in tests and callers assembling rules programmatically.

pub fn allowing(self, ops: impl IntoIterator<Item = DriveOperation>) -> Self

Sets the allow set.

pub fn denying(self, ops: impl IntoIterator<Item = DriveOperation>) -> Self

Sets the deny set.

Trait Implementations

impl Clone for FolderPermissionRule

fn clone(&self) -> Self

Returns a duplicate of the value.

fn clone_from(&mut self, source: &Self)

Performs copy-assignment from source.

impl Debug for FolderPermissionRule

fn fmt(&self, f: &mut Formatter<'_>) -> Result

Formats the value using the given formatter.

impl<'de> Deserialize<'de> for FolderPermissionRule

fn deserialize<__D>(__deserializer: __D) -> Result<Self, __D::Error>

where __D: Deserializer<'de>,

Deserialize this value from the given Serde deserializer.

impl Serialize for FolderPermissionRule

fn serialize<__S>(&self, __serializer: __S) -> Result<__S::Ok, __S::Error>

where __S: Serializer,

Serialize this value into the given Serde serializer.