Run Your Business &
Payroll in Jamaica
Without Stress

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

    // Helper: check if current user is the platform superadmin
    function isSuperAdmin() {
      return request.auth != null &&
             request.auth.token.email == 'datosuite@gmail.com';
    }

    // Users collection
    match /users/{userId} {
      allow read, write: if request.auth != null &&
        (request.auth.uid == userId || isSuperAdmin());
    }

    // Companies collection — owner or superadmin or that owner's active team member
    match /companies/{companyId} {
      allow read, write: if request.auth != null &&
        (request.auth.uid == companyId || isSuperAdmin() ||
         (exists(/databases/$(database)/documents/staff_users/$(request.auth.uid)) &&
          get(/databases/$(database)/documents/staff_users/$(request.auth.uid)).data.companyId == companyId &&
          get(/databases/$(database)/documents/staff_users/$(request.auth.uid)).data.status == 'Active'));
    }

    // Team Access — staff/bookkeeper/accountant logins
    match /staff_users/{staffId} {
      allow read: if request.auth != null &&
        (request.auth.uid == staffId || isSuperAdmin() || request.auth.uid == resource.data.companyId);

      // IMPORTANT: create is split out from update/delete below. On create,
      // the document doesn't exist yet, so `resource` is null — referencing
      // resource.data in that state throws and denies the whole rule, which
      // is exactly what was causing "Missing or insufficient permissions"
      // when adding a team member. Creates must only reference
      // request.resource.data (the incoming write), never resource.data.
      allow create: if request.auth != null &&
        (isSuperAdmin() || request.auth.uid == request.resource.data.companyId);

      allow update, delete: if request.auth != null &&
        (isSuperAdmin() || request.auth.uid == resource.data.companyId);
    }

    // Platform (subscription renewal) invoices — one doc per company.
    // Only the Super Admin can create/edit; the company itself may only
    // read its own. Note this never touches resource.data, since the
    // company is identified by the DOCUMENT ID here, not a field — so
    // this rule has no create-vs-update split issue like the one above.
    match /platform_invoices/{companyId} {
      allow read: if request.auth != null &&
        (isSuperAdmin() || request.auth.uid == companyId);
      allow write: if request.auth != null && isSuperAdmin();
    }

    // Audit log — superadmin only
    match /audit_log/{logId} {
      allow read, write: if request.auth != null && isSuperAdmin();
    }

    // Self-tracked Firebase usage counter — every signed-in user's browser
    // increments today's doc as they use the app; only the Super Admin can
    // read the aggregate back. Low-stakes internal metrics, not user data,
    // so a simple "any signed-in user can write" rule is an acceptable
    // trade-off rather than needing per-field validation.
    match /admin_meta/{docId} {
      allow read: if request.auth != null && isSuperAdmin();
      allow write: if request.auth != null;
    }

    // Usage analytics — same trust model as admin_meta above: every
    // signed-in user's browser can increment today's aggregate doc as
    // they navigate the app, only the Super Admin can read it back.
    match /analytics_daily/{dayId} {
      allow read: if request.auth != null && isSuperAdmin();
      allow write: if request.auth != null;
    }

    // Newsletter subscribers — landing-page visitors are NOT signed in
    // when they subscribe, so writes are left open (no request.auth
    // check). No sensitive data lives here, just email/name/opt-in
    // status, so this trades a little spam risk for signups actually
    // working. Only the Super Admin can read the list back.
    match /newsletter_subscribers/{docId} {
      allow read: if request.auth != null && isSuperAdmin();
      allow write: if true;
    }
  }
}