Pro mode (enabled with npm run pro plus a MongoDB connection) adds four powerful capabilities on top of the standard Domma CMS:

• Views — MongoDB aggregation pipelines exposed as named data sources, embeddable in any page. Query, group, sort and project data from one or more collections and display the results as a table, card grid, list or chart.
• Actions — Multi-step automated workflows triggered manually or by collection events. Chain HTTP requests, collection writes, emails, conditional branches and wait steps in a visual editor.
• Row-Level Access — Per-collection, per-entry access rules evaluated at query time. Rules are expressed as MongoDB filter objects and can reference the current user's id, role, department, or any profile field.
• MongoAdapter — Collections backed by MongoDB instead of flat JSON files. Unlimited scale, full query power, and live aggregation — with no changes to the admin UI or the public content API.

Pro mode is activated by running the setup command once your MongoDB connection string is in place.

# Set MONGO_URI in .env first
echo "MONGO_URI=mongodb://localhost:27017/domma-cms" >> .env

# Run the Pro setup
npm run pro

# Or supply the URI inline without touching .env:
MONGO_URI=mongodb://localhost:27017/domma-cms npm run pro

What npm run pro does:

1. Validates the MongoDB connection using the supplied URI.
2. Creates the necessary internal collections inside MongoDB (_views, _actions, _action_logs, _access_rules).
3. Sets PRO_MODE=true in your .env file.
4. Prints a confirmation message — restart the server to activate Pro features.

The MONGO_URI environment variable accepts any valid MongoDB connection string:

# Local development
mongodb://localhost:27017/domma-cms

# MongoDB Atlas (cloud)
mongodb+srv://username:password@cluster.mongodb.net/domma-cms

# Replica set or self-hosted with authentication
mongodb://username:password@host:27017/domma-cms

Connection management

The connection is handled internally by connectionManager.js, which provides:

• Automatic reconnect — exponential back-off on connection failure, no manual intervention needed.
• Connection pooling — the native MongoDB driver pool is used; the default pool size is 10 and is configurable via the URI options.
• Graceful shutdown — the connection is closed cleanly on SIGTERM / SIGINT, avoiding in-flight write loss.

A View is a saved MongoDB aggregation pipeline given a human-readable name and slug. Views are exposed via the content API and can be embedded directly into pages using the {{view}} template tag.

Creating a View

1. Navigate to Admin → Views → New View.
2. Enter a name, slug and optional description.
3. Select the source collection to run the pipeline against.
4. Build the pipeline using the stage builder or JSON editor.
5. Choose a display mode: table, cards, list, or chart (bar / line / pie).
6. Save and preview live results before publishing.

Example pipeline — top posts by view count:

[
  { "$match": { "published": true } },
  { "$sort": { "views": -1 } },
  { "$limit": 10 },
  { "$project": { "title": 1, "slug": 1, "views": 1, "author": 1 } }
]

Display modes

• table — sortable, paginated data table with configurable columns.
• cards — responsive card grid, useful for media-rich results.
• list — compact vertical list, ideal for sidebars and widgets.
• chart — bar, line or pie chart rendered from aggregated numeric data.

The View Editor in the admin panel provides a visual environment for building and testing aggregation pipelines without writing raw JSON.

Editor features

• Stage builder — add pipeline stages from a dropdown; each stage type renders a dedicated form (e.g. field selector for $project, sort order toggles for $sort).
• JSON editor — switch to raw JSON at any time for full pipeline control; changes sync back to the stage builder.
• Live preview — run the pipeline against real data and inspect results before saving.
• Column configuration — for table display mode, choose which result fields to show, set header labels and control column width.
• Permissions — restrict which user roles can query this View via the API.

Allowed pipeline stages

The editor permits the following stages:

$match, $group, $sort, $limit, $project, $lookup, $unwind, $count, $addFields

An Action is an automated workflow composed of ordered steps. Actions can be triggered manually from the admin panel or fired automatically in response to collection events (entry created, updated, or deleted).

Creating an Action

1. Navigate to Admin → Actions → New Action.
2. Enter a name, slug and optional description.
3. Choose a trigger: manual or a collection event (onCreate, onUpdate, onDelete).
4. Add steps in sequence using the visual step editor.
5. Configure input mapping and error handling per step.
6. Use the test runner to execute the Action with sample data before going live.

Step types

Template interpolation

Use double-brace syntax to reference data within step configuration fields:

• {{input.fieldName}} — trigger input data (e.g. form submission or collection entry)
• {{steps.step1.response.id}} — output from a named earlier step
• {{user.email}} — the user who triggered the Action (if authenticated)
• {{site.title}} — global site configuration values

The Action Editor provides a full visual environment for building, testing and monitoring automated workflows.

Editor features

• Visual step list — steps are displayed as an ordered list; drag to reorder at any time without losing configuration.
• Step forms — selecting a step type renders a context-aware form; for example, HTTP Request shows URL, method, headers and body fields, while Email shows recipient, subject and body.
• Input mapping — for each step, map data from the trigger payload or prior step responses into the current step's variables.
• Test runner — supply a sample input payload and execute the entire Action, seeing step-by-step output, status and response data in a collapsible panel.
• Error handling — configure a retry count (0–5) and choose an on-error branch: stop, continue to next step, or jump to a named step.
• Execution log — view a paginated history of recent runs, each showing trigger time, total duration, per-step status, and any error messages for failed steps.

Row-level access rules let you restrict which entries a user can read or write, based on the content of each document rather than just the collection as a whole. Rules are evaluated at query time inside MongoDB, so unauthorised entries are never transmitted to the client.

How rules work

• Rules are defined per collection in the collection schema.
• Each rule is a MongoDB filter object that may reference the current user via {{user.*}} placeholders — these are substituted server-side before the query is executed.
• The rule filter is merged with any other query filters using $and, ensuring it cannot be bypassed by the client.
• Roles with the bypassRowRules permission (e.g. admin) skip row-level filtering entirely and always see all entries.

Example rules

Configuring access rules

Navigate to Admin → Collections → [Collection Name] → Access Rules. You can define separate read and write rules, and configure which roles bypass row-level filtering.