How can I enforce task organization access in Firestore rules without querying collections?

CONTEXT

Our Firestore data schema is organized as follows:

users collection

• This collection stores documents that correspond to each authenticated user (document IDs match auth.uid).
• It does not include references for organizations or member profiles.

member_profiles collection

• Contains a field user_ref which is a document reference to the users collection.
• Contains an organization_ref field which is a document reference to the organization collection.
• Document IDs here do not match those in the users collection because not all members created by an organization admin need to log in, and a single user may have multiple member profiles.

tasks collection

• Contains an organization_ref (a document reference to the organization collection).

EXPECTED BEHAVIOR

Allow authenticated users to read, create, write, and delete tasks provided that the task's organization corresponds to one of the organizations associated with the user (as determined via the member_profiles document(s)).

CURRENT ISSUE

Below is our attempted Firestore rule using a helper function to get the user’s member profile and validate the organization. It uses a query like .where(...).first(), which isn’t allowed because Firestore rules require a specific document path. This approach currently throws an error:

FIREBASECopied
rules_version = '2';
service cloud.firestore {
  match /databases/{database}/documents {
    // Helper function to get user's member profile
    function getUserMemberProfile() {
      return get(/databases/$(database)/documents/member_profiles)
        .where('user_ref', '==', /databases/$(database)/documents/users/$(request.auth.uid))
        .first();
    }

    // Check if user and resource belong to the same organization using document references
    function isSameOrg(resourceOrgRef) {
      let profile = getUserMemberProfile();
      return profile != null && profile.data.organization_ref == resourceOrgRef;
    }


    // Tasks collection rules
    match /tasks/{document} {
      allow read: if request.auth != null && isSameOrg(request.resource.data.org_ref);
      allow write: if request.auth != null && isSameOrg(request.resource.data.org_ref);
    }
  }
}

ADDITIONAL APPROACH (NOT WORKING)

In an attempt to support users belonging to multiple organizations, we tried storing a list of organization refs in the user document. However, this function generates an 'unknown error':

Supporting doc for using List: https://firebase.google.com/docs/reference/rules/rules.List

FIREBASECopied
rules_version = '2';
service cloud.firestore {
  match /databases/{database}/documents {

    // Check if user and resource belong to the same organization using document references
    function isUserInOrg(taskOrgRef) {
      let userDoc = get(/databases/$(database)/documents/users/$(request.auth.uid));
      return userDoc.exists() && taskOrgRef in userDoc.data.organization_ref;
    }

    // THIS DOES NOT WORK WHEN CHECKING IF TASK ORG (type: document reference) IS IN USER'S LIST OF ORGS (type list of doc ref)
        match /tasks/{document} {
      allow create, write: if request.auth != null && isUserInOrg(resource.data.org_ref);
      allow read: if true;
      allow delete: if request.auth != null && isUserInOrg(resource.data.org_ref);
    }
    // THIS WORKS FINE FOR AUTHENTICATED USERS
    // match /tasks/{document} {
    //   allow create: if request.auth != null;
    //   allow read: if true;
    //   allow write: if request.auth != null;
    //   allow delete: if request.auth != null;
    // }
  }
}

The accepted solution in one of the answers explains that because Firestore rules do not support querying a collection (using methods like .where()), the recommended approach is to pre-store the allowed organization references on the user's document (for example, in an organization_refs array).

This setup allows rules to verify that the task’s organization reference is contained in the user’s list using a simple get() on a fixed document path and an array membership check. The helper function would look like this:

FIREBASECopied
rules_version = '2';
service cloud.firestore {
  match /databases/{database}/documents {
    // Helper function to validate task's organization membership
    function isUserInOrg(taskOrgRef) {
      let userDoc = get(/databases/$(database)/documents/users/$(request.auth.uid));
      return userDoc.exists() &&
             userDoc.data.organization_refs != null &&
             taskOrgRef in userDoc.data.organization_refs;
    }

    match /tasks/{taskId} {
      allow create, update, delete: if request.auth != null && isUserInOrg(resource.data.organization_ref);
      allow read: if true;
    }
  }
}

This example aligns with Firestore's best practices by avoiding dynamic queries in security rules and relying on pre‐computed data in the user document. Please let me know if further clarification is needed on adapting this solution to your schema.