Column Permissions

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:

["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.