Administration Guide

Overview

Administration in dForge covers:

Users — who can access the platform
Roles — what they can do
Folders — what data they can see
Modules — what applications are installed
Settings — module-level configuration

User Management

Navigate to Administration > Users to manage users.

Inviting Users

Click + New to create a user
Enter their email, name, and initial roles
The user receives an invitation to set up their password

Assigning Roles

Each user can have one or more roles. Roles are defined by modules and namespaced — a CRM module might ship crm.manager, crm.sales_rep, crm.viewer; an HR module might ship hr.manager, hr.viewer. There are no generic platform-wide roles.

Roles are additive — permissions from multiple roles are merged (union), never revoked. A user with crm.sales_rep + fin.viewer gets full CRM access plus read-only Finance access. The effective rights are computed as the union of all assigned roles’ rights, never the intersection.

Folder-Scoped Role Assignments

A role assignment can be scoped to a specific folder. This is the primary way to give a user different permissions in different parts of the organization.

folder_id = NULL — the role applies globally (everywhere the user goes)
folder_id = <uuid> — the role applies only within that folder (and its children if inheritance is enabled)

Example: a user can be hr.manager globally but only hr.viewer inside the HR/Executives folder, so they can manage everyone except the executive team.

Direct User Rights (Overrides)

In addition to role-based rights, admins can grant or override rights for an individual user on a specific security object via user_rights. Use this sparingly — for one-off exceptions where creating a new role isn’t justified.

Role System

Entity Rights

Roles grant rights on entities:

Right	Code	Meaning
Select	S	View/query records
Insert	I	Create new records
Update	U	Edit existing records
Delete	D	Remove records
Clone	C	Duplicate records

Action & Report Rights

Right	Code	Meaning
Execute	E	Run an action or report

Folder Access

Right	Code	Meaning
Access	E	Enter and work within a folder

Folder System

Folders are dynamic filtered views, not physical containers. A record doesn’t “live” in a folder — it appears in the folder when it matches the folder’s filter, and it can appear in many folders at once.

How Folders Work

Row filter — each folder defines a filter that determines which records are visible inside it. The filter is applied to every query made from within the folder.
Entity view — each folder binds entities to a specific entity view, which controls which columns the user can see. Different folders can show different columns of the same table.
Role assignments — roles can be assigned at the folder level, so the same role gives different permissions in different folders.
Settings overrides — module settings can be overridden per folder and inherit down the tree.
Hierarchy — folders are hierarchical. Children inherit security and settings from their parent unless explicitly isolated.

Composable Security

Effective access in dForge is the intersection of three independent dimensions:

Access = Folder (rows) × Entity View (columns) × Role (operations)

Folder decides which rows you can see (row-level security via filter)
Entity view decides which columns you can see (column-level security)
Role decides what you can do with what you see (S, I, U, D, C, E)

Example

A product catalog used by two departments:

Warehouse folder — entity_view = storekeeper_view exposes name, sku, quantity, location. Roles assigned here grant S, U on the product entity.
Accounting folder — entity_view = accountant_view exposes name, sku, price, cost, margin. Roles assigned here grant S, U on price and cost only.

Same product table, two completely different experiences. No data duplication.

Greyed-Out Folders

If a user has access to a sub-folder but not to its parent, the parent is shown in the tree as non-selectable (greyed out). They can navigate down to the sub-folder they own without ever seeing parent data.

Module Management

Installing Modules

Go to the Module Installer
Browse available modules
Click Install — dForge creates tables, views, menus, roles, and seed data
Assigned users can immediately start using the new module

Module Dependencies

Some modules depend on others:

Pricing requires WMS (uses product and category entities)
CRM-Finance bridge requires both CRM and Finance
Integration bridges add cross-module features without modifying core modules

Uninstalling Modules

Uninstall soft-deletes the module (sets it inactive) while preserving data for referential integrity. The module’s menus and views are hidden, but data remains accessible for audit and reporting.

Module Settings

Modules can define configurable settings. Access them via Settings for each installed module.

Settings are folder-scoped — values inherit through the folder tree. A setting defined at the company level applies to all sub-folders unless overridden at a more specific level. Resolution walks up the tree until it finds a value, then falls back to the module default. If nothing is set anywhere, the value is NULL.

Examples:

Invoice number prefix per business unit
Default currency per region
Approval thresholds per department

Settings can be referenced in formulas with $[SettingName]:

[amount] <= $[ApprovalThreshold]      -- canExecute on an Approve action
[department_id] = $[DepartmentId]     -- row-level security filter
$[DefaultWarehouseId]                 -- default value for new records

This is how the same module can adapt to different organizational structures without changing any code — admins just configure the values per folder.

← previous User Guide next → Core Concepts