# Column Permissions [back to permissions](README.md) /// [home](../README.md) Beyond table level access the server must be able to also control individual columns access permissions. This is to be done through `advanced_rules` in the permission config (or just the combined permissions column in the db). A compliant server should support all of these. ## Format Column rules use `"table.column:code"` format: ```json ["vfy_items.price:block", "jde_users.password:block", "jde_users.email:r"] ``` Wildcard: `"table.*:code"` applies to all columns on that table, not sure why you'd use that but whatever ## Column Permission Codes | Code | Name | Can read | Can write | Notes | |---------------|---------------------|----------|-----------|------------------------------------------------------| | `block` / `b` | block | no | no | column is invisible | | `bo` | block own | no | no | blocked if the row is owned by you | | `bg` | block group | no | no | blocked if the row is owned by someone in your group | | `boi` | block own inverse | yes | yes | blocked UNLESS you own the row | | `bgi` | block group inverse | yes | yes | blocked UNLESS someone in your group owns the row | | `r` | read only | yes | no | can see it but cant change it | | `rw` | read write | yes | yes | full access to this column | | `rwa` | read write all | yes | yes | full access including system managed cols | ## How blocking should work ### On select Blocked columns (`b`, `bo`, `bg`) should be stripped from the results. They just dont appear in the returned data. If json derolu stripped for you a `warning` field should be included in the response telling you the hot stripping actions by jaysonderulo. ### On insert and update Columns with `block`, `bo`, `bg` or `r` (read only) should be cause json derulo to strip for you (removes illigal data you sent). You can try to set them but theyll be ignored because of jsons hot body. Again a `warning` should tell you if jsonderulo stripped for you. ## System columns Some columns should be write protected by default even without explicit column rules: - `created_at`, `created_by`, `last_modified_at`, `last_modified_by`, `pinned_to` - plus any columns listed in `write_protected_columns` in the toolkit config These should only be writable if your table permission is `rwa`.