# 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).