Skip to content

Administrator guide

This section is for site administrators and Content Managers. It covers everything you need to configure, operate, and customize a FedMS instance — short of writing PHP code. For developer-level work, see the Developer guide.

The Administrator guide covers two distinct kinds of work:

Site administrator (DevOps / Admin role) Content Manager / Manager
Email transport, system settings, users, permissions, recipes, monitoring, backups. Event types, session types, attachment types, task patterns, books, page content.

In practice, the same person often holds both hats on a small instance. On larger instances they are different people.

In this section

Configuration

Users and permissions

Content types

Workflow

Optional features

  • Recipes — installing and configuring the optional features (Send Email, Zoom Video, Attachment Recording).
  • Reports — running reports and exporting data.

Where everything lives

Area Admin URL
Site-wide configuration /admin/config
Structure (event/session/attachment types, paragraphs, fields) /admin/structure
People (users) /admin/people
Permissions /admin/people/permissions
Task patterns /admin/structure/fedms-task-pattern
Reports /admin/reports
ECA models /admin/config/workflow/eca

Operational notes

A FedMS instance is a real Drupal installation. The standard Drupal admin tools apply — caches, performance, logging, cron — and they are all under /admin/config/development and /admin/reports.

If you need to drop into a shell to run Drush or look at logs, the L3D environment is the supported way on developer machines. On the managed SaaS, the LakeDrops operations team handles this; you should not need a shell.

A few golden rules

  1. Never edit config in production by hand unless you intend to re-export it back to the source repo. Otherwise the next deployment will overwrite it.
  2. Always test recipes in dev first. Some recipes have side effects (installing modules, modifying mail settings) that you don't want to discover in production.
  3. Backups before structural changes. Adding or removing fields on a content type, changing a paragraph type — make sure a recent backup exists.
  4. Read the issue tracker. Many "how do I do X" questions have been answered in the GitLab issues.