JsonDerulo-API-Spec/permissions

Permissions

back to index

How jsonderulo decides what you can and cant do (and how to punish you!)

Pages

• Table Permissions the permission codes that control read/write access per table
• Column Permissions fine grained column level access control
• Ownership Scoping 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.

{
  "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"
      }
    }
  },
  "max_limit": 1000,
  "max_where": 20,
  "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). 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.

max_limit the resolved maximum number of rows the user can request per query. comes from the users power level config (per-group max_limit in jde_groups or the power level config in security.toml) capped by default_max_limit in security config. Clients should use this to cap their own limit inputs and inform the user.

max_where the resolved maximum number of WHERE conditions the user can use per query. same resolution as max_limit per group or per power level, capped by default_max_where_conditions. Clients can use this to limit filter complexity in their UI.

user_settings_access tells you what you can do with the preferences 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).