Settings reference

Help Tutorials has no config_schema fields — the module is a binary on/off. All operational state lives in two tables created lazily on first use:

Tables

• help_tutorials — one row per (page_key, language). Stores the tutorial body, steps JSONB, settings_help JSONB, video_url, is_active.
• help_tutorial_reads — one row per (user_id, page_key). Stamps read_at when a user opens the help panel for that page. Used to hide the "new" dot.

Both tables are CREATE TABLE IF NOT EXISTS from ensureHelpSchema — they auto-create on first read or write, so freshly provisioned tenants do not need a dedicated migration.

Privileges (Wave 11)

Reading a tutorial requires no privilege — every authenticated admin can open the help panel.

Endpoints

• GET /admin/help-tutorials/{pageKey} — fetch the tutorial for a page (auto-seeds on miss).
• POST /admin/help-tutorials/{pageKey}/read — mark as read for the current user.
• GET /admin/help-tutorials/unread — list page_keys with unread tutorials for the current user (used to render dots in the sidebar).
• GET /admin/help-tutorials/exists?keys=a,b,c — bulk existence probe (used by admin shells to decide which pages to render the help icon on).
• GET /admin/help-tutorials/ — list all (admin author view, paginated, supports search).
• POST /admin/help-tutorials/ and PUT /admin/help-tutorials/{id} — upsert.
• POST /admin/help-tutorials/seed — fill missing rows from the default set.

Recommendations

• Keep the en rows seeded even if your admins use another language. Costs nothing and gives the fallback content.
• Don't disable the module to "hide" specific tutorials — toggle individual rows' is_active instead.
• When customising the seed defaults at the platform level, version the migration so re-seeded tenants pick up new rows without overwriting their edits.