Managing data permissions

Each table has four permissions: create, read, update and delete. Describe what you want in the chat and Draftship writes the rules:

Defaults

Tables without their own rules allow anyone to create and read records, and only the creator to update or delete them. Anonymous records (no signed-in user) can only be changed by admins.

What the rules look like

Rules live in each table's schema file. See Security rules for the full format.

"rls": {
  "create": true,
  "read": { "user_condition": { "role": "admin" } },
  "update": { "user_condition": { "role": "admin" } },
  "delete": { "user_condition": { "role": "admin" } }
}

Hiding single fields

Sometimes records should be public but one field should not, like the email on a guestbook note. Field-level rules ("fls") hide a field from everyone who doesn't pass its rule, and can also block who may set it:

"fls": {
  "author_email": {
    "read": { "$or": [{ "created_by": "{{user.email}}" }, { "user_condition": { "role": "admin" } }] }
  },
  "status": {
    "write": { "user_condition": { "role": "admin" } }
  }
}

Hidden fields are removed before filters run, so they can't be guessed with queries. created_by can be hidden the same way. The security scan adds these rules for you with Apply fix.

Check the result

Use the Data tab to see what's stored, and test your app signed out and as a second user to confirm that each person sees only what they should.