SODa SCS Manager

SODa SCS Manager turns Drupal into a self-service control panel for the SODa Semantic Co-Working Space (SCS). Researchers and collection staff create projects, invite collaborators, and add research apps — WissKI environments, a shared JupyterLab, WebProtégé, SQL databases, and OpenGDB triplestores — without installing software locally or learning Docker. Each project gets a Nextcloud Team Folder for its files.

If you are new to Drupal: you mainly use a dashboard and wizards. Drupal hosts the UI, users, and configuration; the module talks to Keycloak (login), Portainer/Docker (containers), MariaDB, Nextcloud, JupyterHub, and related services in the background.

What solution does this module provide? A project-centric platform to provision, share, monitor, and tear down SCS applications with SSO, membership sync, snapshots, and connected-account management — so cultural-heritage and research teams get FAIR-oriented tooling without a dedicated ops person for every instance.

Try it / run it: Production/reference deployment at scs.sammlungen.io. Full stack (Drupal, Keycloak, Nextcloud, JupyterHub, OpenGDB, WebProtégé, project website, Traefik, and operator docs): soda_scs_manager_deployment. For most adopters, that Compose environment is the supported way to run SODa SCS Manager — not a plain Drupal site alone. Current release: 3.1.0.

Features

Basic functionality

• Project dashboard — after login, users see Your projects as cards (members, status). Applications are opened from the project page, not from a separate central-services block. New accounts start without a project.
• Create-project wizard — name, applications, and invitations are held until a review step. The project is created only when that review is confirmed. Project names are unique (a machine name is derived from the label; scs-share is reserved).
• Applications, each tied to exactly one project — WissKI environment (Drupal/WissKI + database + triplestore), MariaDB (phpMyAdmin via SSO), OpenGDB triplestore, JupyterHub, and WebProtégé. JupyterHub and WebProtégé exist at most once per project; the others can be added more than once.
• Shared JupyterLab — one lab per project, with real-time collaboration. Members open it from the project card; start, stop, and restart apply to that shared server. The project Team Folder is mounted into the lab through a Nextcloud service account.
• WebProtégé — adding it creates (or reuses) an ontology project and grants members edit access. Removing it moves that ontology project to trash.
• Project files — every project has a Nextcloud Team Folder. The project page lists recent activity in that folder for owners and members. There is no separate Nextcloud stack to provision.
• Identity and access — OpenID Connect / Keycloak SSO; project membership synced to Keycloak groups; service keys and connected accounts. Owners invite by email or username. Invitations live in a Messages inbox (accept, decline, withdraw, resend).
• Lifecycle — create and delete provisioning, health (running, starting, stopped, problem, unknown), start/stop/restart for dedicated containers from the health icon, snapshots for backup and restore, secure logging with credential redaction.

When / why use it

• You run (or plan) a multi-tenant research platform for collections, digital humanities, or museum data.
• Users need self-service WissKI, Jupyter, SPARQL, and SQL, plus a shared project folder, without ticket-driven VM setup.
• You want one Drupal-facing UX wired to Keycloak and container orchestration.

Typical use cases

• A research group creates a project, adds a WissKI environment with the default data model, and works in the project Team Folder.
• A curator adds a SQL database and opens it in phpMyAdmin via SSO.
• A data scientist adds JupyterHub; every member uses the same JupyterLab, with the Team Folder already mounted.
• An ontology editor adds WebProtégé and edits the project ontology under the same login.

Post-Installation

This module is meant to run inside the SODa SCS Manager deployment (or an equivalent stack), not as a drop-in on a bare Drupal site.

1. Deploy the stack — follow soda_scs_manager_deployment (clone, submodules, .env from example-env, ./start.sh, docker compose up -d, then the Zensical post-configuration docs for Keycloak, Nextcloud, DBMS SSO, and the rest).
2. Enable the module — place the companion theme soda_scs_manager_theme in themes/custom first. It is not a module dependency; install checks that it is present, and hook_install() enables it. Rebuild theme assets (npm install / npm run build in the theme) if you maintain CSS.
3. Configure settings — go to Administration → Configuration → SODa SCS Manager (/admin/config/soda-scs-manager). Set integration endpoints and secrets (Keycloak, Portainer/Docker, Nextcloud, JupyterHub, WebProtégé, mail/SMTP, security/logging).
4. OpenID Connect — configure the OpenID Connect client so users log in via Keycloak.
5. Permissions and roles — grant SCS users permission to manage their own stacks, components, and projects, plus Manage own connected accounts. Keep admin permissions restricted.
6. User-facing entry — after login, users land on the Dashboard. They create a project there and add applications with + on the project page. Connected Accounts covers Nextcloud mount status and related links.
7. Translations — German UI strings ship as translations/soda_scs_manager.de.po; import via Locale or Drush if needed.

Special considerations: Every application belongs to exactly one project. Provisioning needs working Docker/Portainer and the service APIs. Nextcloud Team Folders and Keycloak groups are synced when a project is created, updated, or deleted. A new project is rolled back if the Keycloak group fails or Nextcloud already has a folder with that name. Post-install hooks in companion services (for example Nextcloud) may need a one-time occ step on existing installs — see the deployment docs.

Additional Requirements

• Drupal 10 or 11 (module: ^10 || ^11). PHP 8.1 or later.
• Drupal dependencies (declared): Language (core), OpenID Connect, SMTP, Field Group, and the soda_scs_manager_theme theme (required at install, not listed as a module dependency).
• Composer: composer require 'drupal/soda_scs_manager:^3.1'. That installs the module only. Working provisioning needs the deployment stack above.
• Infrastructure (required for real use): Keycloak (SSO, groups, attributes), Docker and Portainer (or equivalent) for container lifecycle, MariaDB, Traefik (or a similar reverse proxy), Nextcloud with the scs_manager_integration app, JupyterHub, OpenGDB, and WebProtégé as configured in the deployment. Reference wiring: soda_scs_manager_deployment.
• Host tools for operators: Docker, Git (submodules), jq, curl; Node/npm on the host for theme builds.

Recommended modules/libraries

• soda_scs_manager_theme — companion theme (Tailwind/PostCSS). Styling lives there, not in the module.
• OpenID Connect plus the Keycloak realm and clients documented in the deployment.
• SMTP — outbound mail for invitations and notifications.
• Platform companions from the SODa stacks (Nextcloud scs_manager_integration, WissKI base images, the default WissKI data model) extend what the manager can provision.

Similar projects

• Generic Drupal multisite / Aegir / Pantheon-style hosting panels manage Drupal sites. They do not provision WissKI, a triplestore, JupyterLab, and a Nextcloud Team Folder as one research product with Keycloak project groups.
• Cloud control panels (Rancher, Portainer UI alone) are ops tools. SODa SCS Manager is an end-user research dashboard on top of that stack.
• WissKI, Islandora, and other digital-humanities Drupal distributions focus on a single research CMS or repository. This module orchestrates many user-owned environments and shared services around SODa SCS.

Differentiation: project-scoped self-service for a defined SCS toolset (WissKI, a shared JupyterLab, WebProtégé, SQL, OpenGDB, Nextcloud Team Folders) with SSO and membership sync.

Supporting this Module

SODa SCS Manager is developed in the SODa project (Sammlungen – Objekte – Datenkompetenzen). For issues and contributions, use the GitHub organisation soda-collections-objects-data-literacy and the deployment and module repositories linked there.

Community Documentation

• Live platform: https://scs.sammlungen.io
• Deployment and operator docs (Zensical): soda_scs_manager_deployment — build and browse as described in that repository’s README. A running stack serves them at docs.<subdomain>.<base-domain>.
• SODa / SCS background: https://sammlungen.io · SODa Semantic Co-Working Space (Zenodo)
• Module README in the module repository (hooks, content sync, secure logging, theming). In-app documentation is linked from the manager UI.

Additional information

• Licensed under GPL-2.0-or-later (GPL-2.0+), matching Drupal core.
• UI language: English, with German translations maintained in the module.
• Security: use the module’s secure logging helpers. Do not leave database passwords or app secrets in plain logs. Nextcloud app passwords are stored as encrypted Drupal user data.
• This is not a content-type module for site builders. Expect custom entities (projects, stacks, components, snapshots, service keys) and a dashboard-first UX.