JAYSON DERULO

4 files changed, 236 insertions, 0 deletions

diff --git a/permissions/README.md b/permissions/README.md
new file mode 100644
index 0000000..881daa7
--- /dev/null
+++ b/permissions/README.md
@@ -0,0 +1,89 @@
+# Permissions
+
+[back to index](../README.md)
+
+How jsonderulo decides what you can and cant do (and how to punish you!)
+
+## Pages
+
+- [Table Permissions](table_permissions.md) the permission codes that control read/write access per table
+- [Column Permissions](column_permissions.md) fine grained column level access control
+- [Ownership Scoping](ownership.md) how pinned_to restricts which rows you can see and modify
+
+## GET /permissions
+
+Call `GET /permissions` with your token to see what you have access to. This should be the one stop shop for a client to figure out what parts of jsonderulo you are allowed to molest.
+
+```json
+{
+  "success": true,
+  "user": {
+    "id": 1,
+    "username": "admin",
+    "name": "Admin User",
+    "role": "administrators",
+    "power": 100
+  },
+  "permissions": {
+    "jde_settings": "rw",
+    "jde_groups": "rw",
+    "jde_users": "rw"
+  },
+  "column_rules": {
+    "jde_users.password": "block",
+    "jde_users.pin_code": "block"
+  },
+  "toolkits": {
+    "beepzone": {
+      "type": "application",
+      "group": "managers",
+      "permissions": {
+        "assets": "rw",
+        "transactions": "rw",
+        "audit_log": "r"
+      },
+      "column_rules": {
+        "transactions.amount": "r",
+        "assets.serial_number": "block"
+      }
+    },
+    "opensigma": {
+      "type": "library",
+      "group": "admins",
+      "permissions": {
+        "sigma_config": "rw"
+      }
+    }
+  },
+  "user_settings_access": "read-write-own"
+}
+```
+
+### Whats in here
+
+**`permissions`** for core tables and compatability with the few unoficial internal jde v1 tools I made (usually adminier stuff or user table partial read for joins all depicted from `jde_groups` aka. core_groups). Tables that belong to toolkits shouldn't show up here lol.
+
+**`column_rules`** same as above but for column level rules like this `"table.column": "permission_code eg. block"` entries for core table columns with explicit column level rules (see [column permissions](column_permissions.md)). Only present when there are any obviously.
+
+**`toolkits`** is an part of json derulos body grouped by toolkit name. Each toolkit entry should include:
+- `type`: `"application"` or `"library"` so clients know what kind of toolkit it is and whether to show it as a selectable application or not
+- `group`: the users resolved toolkit group name (from `jde_associations` or `toolkit_overrides`). missing if no association exists but thats something that shouldnt really occure as then that entire toolkit shouldnt even be shown to the user.
+- `permissions`: table permission map for this toolkit only
+- `column_rules`: column level rules for this toolkits tables (only present when there are any). same `"table.column": "code"` format
+
+This way a client can see at a glance which toolkits they have access to, what group they are in for each one, what parts of json derulos body they can molest and what column level restrictions exist and by that effectively be able to decide what feature to show or not.
+
+**`user_settings_access`** tells you what you can do with the [preferences](../admin/preferences.md) endpoint.
+
+## How permissions should be resolved
+
+Permissions come from two layers that get merged:
+
+1. **Core permissions** from `jde_groups` (your core group has a power level and permission rules)
+2. **Toolkit permissions** from toolkit group tables (linked via `jde_associations`)
+
+A compliant server should merge these at startup and on config reload. The final resolved permissions for your power level determine what jsonderulo lets you do.
+
+Wildcard rules like `"*:r"` should apply to all tables that dont have an explicit rule.
+
+Read only tables (configured in toolkit definitions) should automatically downgrade any writable code to its read only equivalent (`rw` becomes `r`, `rwg` becomes `rg`, etc).
diff --git a/permissions/column_permissions.md b/permissions/column_permissions.md
new file mode 100644
index 0000000..120e9f7
--- /dev/null
+++ b/permissions/column_permissions.md
@@ -0,0 +1,44 @@
+# 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`.
diff --git a/permissions/ownership.md b/permissions/ownership.md
new file mode 100644
index 0000000..a91d196
--- /dev/null
+++ b/permissions/ownership.md
@@ -0,0 +1,41 @@
+# Ownership Scoping
+
+[back to permissions](README.md) /// [home](../README.md)
+
+When you have a get noscoped permission code (`rwo`, `rwg`, `ro`, `rg`) jaysonderulo must automatically restrict which rows you can see and modify. This is done through the `pinned_to` system column.
+
+## How pinned_to works
+
+`pinned_to` is a by default auto managed system column that should be added to tables (unless the table opts out). When you insert a row `pinned_to` gets set to your user ID.
+
+The server should use this column to filter rows based on your permission level:
+
+### Own scoping (rwo, ro)
+
+Should add `WHERE table.pinned_to = <your_user_id>` to every query. You can only see and modify rows where `pinned_to` equals your own user ID.
+
+### Group scoping (rwg, rg)
+
+Should add a subquery filter that checks if `pinned_to` belongs to any user in the same core group as you. So you can see rows created by anyone in your core group afaik but not by people in other groups.
+
+## On insert
+
+When you insert a row:
+- `pinned_to` should be automatically set to your user ID
+- if you have `rwa` permission you can explicitly set `pinned_to` to someone else (like assigning a row to another user)
+- with any other permission code you cant override `pinned_to`, its always you so json derulo can strip for you <3
+
+## On update and delete
+
+The ownership filter should be applied to the WHERE clause so:
+- with `rwo` you can only update/delete rows you own
+- with `rwg` you can only update/delete rows owned by someone in your group
+- with `rw`/`rwa` theres little/no restriction (unless overwritten by advanced type rules)
+
+## On select and count
+
+Same deal. The filter should be injected so you only see rows youre allowed to see. Count only counts rows you have access to.
+
+## Tables without pinned_to
+
+If a table has opted out of the `pinned_to` system column (via `system_column_overrides`) then ownership scoping cant work on it. So dont give ownership scoped permissions (`rwo`, `rwg`, `ro`, `rg`) to tables that dont have the `pinned_to` column, How the server handles such exceptions is not explecityly rules for JDE v2 so either jsonderulo hangs itself because he cant serve your request or it might just give the permission without `o` or the `g` addition. Will be spanked to be standardized in future jde revisions.
\ No newline at end of file
diff --git a/permissions/table_permissions.md b/permissions/table_permissions.md
new file mode 100644
index 0000000..884744e
--- /dev/null
+++ b/permissions/table_permissions.md
@@ -0,0 +1,62 @@
+# Table Permissions
+
+[back to permissions](README.md) /// [home](../README.md)
+
+Every table has a permission code that controls what actions are allowed. These are set in the groups config (both core groups and toolkit groups). A compliant jsonderulo server must support all of these.
+
+## Permission Codes
+
+| Code | Name | Read | Write | Row Restriction |
+|------|------|------|-------|----------------|
+| `rwa` | read write all | yes | yes | none (can also write system columns) |
+| `rw` | read write | yes | yes | none |
+| `rwg` | read write group | yes | yes | only rows owned by users in your group |
+| `rwo` | read write own | yes | yes | only rows you own |
+| `r` | read | yes | no | none |
+| `rg` | read group | yes | no | only rows owned by users in your group |
+| `ro` | read own | yes | no | only rows you own |
+
+## What the codes mean
+
+### Full access codes
+
+**rwa** is the admin code. full read and write plus the ability to write system columns directly (like setting `pinned_to` to another user on insert). Only give this to trusted admin groups obviously.
+
+**rw** is standard read write. You can read and write everything but system columns should be auto managed by the server, you cant override them.
+
+### Scoped write codes
+
+**rwg** lets you read and write but only rows where `pinned_to` belongs to a user in the same core group as you. Good for team based access where a team can see and edit their own teams stuff.
+
+**rwo** same but personal. you can only touch rows where `pinned_to` equals your own user id.
+
+### Read only codes
+
+**r** read everything, write nothing.
+
+**rg** read only rows belonging to your groups users.
+
+**ro** read only your own rows.
+
+## Format in config
+
+Permission rules are stored as JSON arrays of `"table:code"` strings:
+
+```json
+["*:rw", "jde_settings:r", "vfy_logs:r"]
+```
+
+`*` is the wildcard. It applies to every table that doesnt have its own explicit rule. So in the example above every table gets `rw` except `jde_settings` and `vfy_logs` which are read only.
+
+## Read only tables
+
+Tables marked as `read_only` in the toolkit config should automatically have their writable codes downgraded:
+
+| Original | Downgraded to |
+|----------|--------------|
+| `rwa` | `r` |
+| `rw` | `r` |
+| `rwg` | `rg` |
+| `rwo` | `ro` |
+
+So even if your group gives you `rw` on a read only table you effectively only get `r`.