Tags

4.4.0

4.4.0

- The WissKI create form has a checkbox "With WissKI Default Data Model",
  checked by default. Without it, the WissKI starts as a plain Drupal/WissKI
  site with the triplestore adapter but without the WissKI ontology and the
  default data model. Needs a WissKI base image that accepts an empty
  `WISSKI_DEFAULT_DATA_MODEL_VERSION`. **Run `drush updb` (update 11040).**
  Related: [#3637662](https://www.drupal.org/project/soda_scs_manager/issues/3637662).

- URLs of deleted or unknown components, stacks, projects and other SCS
  entities show the "Page not found" page (404) instead of "Something went
  wrong" (500).
  Related: [#3637698](https://www.drupal.org/project/soda_scs_manager/issues/3637698).
- Pages of the SCS Manager no longer show the PHP 8.4+ deprecation
  "Implicitly marking parameter $machineName as nullable" from
  `SodaScsOpenGdbHelpers::createUser()`; the parameter is now explicitly
  nullable.
  Related: [#3637657](https://www.drupal.org/project/soda_scs_manager/issues/3637657).
- Creating an application that fails now shows one message that names the
  failed step and, where it is safe, the reason (database name taken,
  Nextcloud account not connected, Team Folder not ready) instead of
  "Cannot create stack … See logs". The log entry keeps the original
  exception and its backtrace instead of "Unknown error occurred". A failed
  triplestore repository request now stops the creation instead of saving a
  triplestore without repository.
  Related: [#3637658](https://www.drupal.org/project/soda_scs_manager/issues/3637658).
- Creating a WissKI no longer fails when its Drupal container starts a few
  seconds after the stack: the SCS Manager waits up to 30 seconds for it and
  otherwise looks the container up later. The container is matched by its
  exact name, so a WissKI can no longer store the container of another
  WissKI whose name contains its own.
  Related: [#3637658](https://www.drupal.org/project/soda_scs_manager/issues/3637658).

- The "Something went wrong" error page no longer prints the exception
  message, which anyone, including anonymous visitors, could see (e.g. SQL
  errors or service host names). The message stays in the log.
  Related: [#3637698](https://www.drupal.org/project/soda_scs_manager/issues/3637698).

4.3.3

4.3.3

- Create-application forms derive an empty machineName from the label while
  the POST is read (#value_callback), before Form API #required runs. The
  field stays required. The 4.3.2 derive in validateForm() was too late.
  Related: #3637344.

4.3.2

4.3.2

- The Create Project wizard creates selected applications even when JS
  aggregation is on (as on production). The stack and component create forms
  derive `machineName` from the label on the server if the client left it
  empty, and validation messages name the field again
  (`#title_display` invisible instead of an empty title).
  Related: [#3637344](https://www.drupal.org/project/soda_scs_manager/issues/3637344).

4.3.1

4.3.1

- The German translation file is valid gettext again (`msgfmt -c` reported
  34 errors). Three strings of the Keycloak registration form lacked their
  closing quote, so their German text never reached the form; 31 duplicate
  entries are merged, keeping the translation the import used so far.
- Gin's status field template no longer triggers a PHP 8.5 deprecation on
  non-node Views (for example People). When the row has no
  `node_field_data_langcode`, preprocess fills it from the row entity's
  language so `hasTranslation()` gets a string instead of `NULL`.

4.3.0

4.3.0

- The module ships its own UI styles: `css/soda-scs-manager.css`, built from
  `pcss/` with `npm run build`. The `globalStyling` library no longer depends
  on `soda_scs_manager_theme`, and installing the module no longer needs or
  installs that theme.

- The dependency on `soda_scs_manager_theme`. Update 11039 uninstalls the
  theme (with its blocks and settings) unless it is the default or admin
  theme; on sites where its files are already gone it is removed from the
  installed themes. **Remove `web/themes/custom/soda_scs_manager_theme`**
  after the update.
- The site-wide styles that came with the theme bundle: Tailwind's preflight
  reset, the `html`/`body` font (Inter), Olivero/Claro page-frame and
  cookie-banner rules. In the SCS deployment `scs_custom_theme` provides them
  now; **another front theme must bring its own base reset and fonts**.

4.2.0

4.2.0

The tag `4.1.1` on git.drupal.org was never released; its changes are part of this release.

- SCS system check, in the Drupal status report (`/admin/reports/status`)
  and as `drush scs:check` (`--problems` lists only warnings and errors;
  exits with 1 on errors). It checks the required SCS Manager settings,
  reaches MariaDB (root), Portainer (with its token), Keycloak, Nextcloud,
  the Nextcloud mount sidecar, the triplestore, JupyterHub and WebProtégé,
  checks the snapshot directory and its free space, the host timers, the
  demo and WissKI update queues and whether every WissKI container runs.
  The status report reuses a run for five minutes.
- `drush scs:heartbeat <name>`: the systemd timer units call it after each
  run, so the system check can tell a missing or stopped host timer.
  **Re-copy the unit files** from `01_scripts/global/` to
  `/etc/systemd/system/` and run `systemctl daemon-reload`.

- The version card of a WissKI instance names the running build as
  "<commit> from <date>", and for development instances the commit and build
  date of the next image (read from the image registry). The update button
  names its target ("Update to 5.6.1").

- WissKI updates run as queued background jobs instead of inside the web
  request, which php-fpm ends after 600 seconds, possibly in the middle of a
  rollback. The update button, "Set package environment" and the automated
  updates form queue the update (queue `soda_scs_manager_wisski_update`) and
  start `drush queue:run` in the background; updates run one after the
  other, and a lock keeps a second update of the same instance from
  starting. The version card shows "Update running" with the current step
  while it runs, reloads when it ends, and shows the outcome for a day. The
  Update button is hidden while an update is queued or running.
  The host timer `scs-wisski-update-queue.timer` (deployment repo,
  `01_scripts/global/`) picks up updates whose background run did not start.

- The onboarding tour now outlines all relevant clickable file, application,
  and subsystem controls using the colours shown in the instructions.
- WissKI updates no longer destroy data when the database update fails. The
  rollback could cut a site's database in half: it ran inside the old Drupal
  container while Portainer was still replacing it, so the restore was
  killed mid-import (seen on a development instance, whose `config` table
  lost every row after `views.view.*`).
  - After the redeploy, the update waits until Portainer has actually
    replaced the Drupal container (up to three minutes) before it checks
    health and runs `drush updatedb`.
  - The pre-update dump is written from the MariaDB container to
    `<snapshot root>/.wisski-update-backups/<instance>/<timestamp>.sql`
    instead of `/opt/drupal/bkp` inside the WissKI container, which did not
    survive the redeploy. The dump is checked for completeness; the three
    newest updates keep their dumps.
  - `drush updatedb` is retried twice before the update counts as failed, so
    a dropped Redis connection right after the redeploy no longer triggers a
    rollback.
  - The rollback stops the WissKI container, dumps the current state to
    `<timestamp>-failed-update.sql`, and restores from inside the MariaDB
    container. The error names the dump files.
- A failed WissKI update now returns to the previous version, not only the
  previous database. Before the redeploy the manager records the Portainer
  env, the compose stack ref and the running Drupal image by registry digest
  (`main@sha256:…`, so this also works for development instances on a
  rolling tag), plus the entrypoint's package-set marker. Any failure from
  the redeploy on (redeploy error, Drupal not healthy, `drush updatedb`)
  restores the database, resets the marker so the old entrypoint does not
  re-import recipe config, redeploys the recorded state, and leaves
  maintenance mode once Drupal is healthy. If the previous version cannot be
  redeployed, the site stays in maintenance mode on the new image with the
  restored database.
- A failed pre-update dump no longer leaves the site in maintenance mode.
- Operations never left their first status: `updateOperation()` called
  `fields()` once per field, and each call replaced the previous list, so
  only the `updated` time was written. Completed and failed operations now
  say so.
- Progress steps stored their time as single-precision float, which rounds a
  Unix timestamp to about two minutes, so the steps of an operation came
  back in random order. Update 11038 changes `soda_scs_steps.created` to
  double.

4.1.1

4.1.0

4.1.0

4.0.0

3.1.0

3.1.0

3.0.0

3.0.0

Development line: branch `3.x`. Major release relative to `2.4.x` (application-centric dashboard).

- Dashboard is **project-centric**: **Central services** (Nextcloud, Jupyter, WebProtégé) above **Your projects** as cards (apps with Online/Offline, member count). Application creation moves to the project page for owners via `(+)` (with `?project=` on create forms); the old flat “add application from dashboard” UX is no longer the primary flow.
- Applications (components and stacks) may belong to **at most one** project (enforced on save + project sync; update `11026` collapses legacy multi-links: stack project → owner default → first listed).
- Breadcrumb root for SCS users is **Dashboard** (route `soda_scs_manager.dashboard`) instead of Home/Startseite (`<front>`). Entity pages append the current title as a non-linked crumb; components/stacks include the related project when set.
- New WissKI stacks use `NEXTCLOUD_MOUNT_MODE=external` and bind only the **project Team Folder** (`NEXTCLOUD_USER_MOUNT_SOURCE=…/<owner>/<project-label>` → `private://nextcloud`); app passwords are no longer injected into new WissKI stacks. Existing stacks need a re-deploy after a final bisync push (see nextcloud_webdav_mount migration notes).

- Nextcloud sidecar mount lifecycle: `NextcloudMounterClient`, encrypted Drupal storage for app passwords, `NextcloudMountManager` reconciler (cron ~1 min), and Drush `scs:nextcloud-mount|unmount|reconcile|status`.
- Connected Accounts shows Drive mount status (`mounted` / `error:…` / `disconnected`).
- Nextcloud stack entity preview with recent file activity.
- Details link on Nextcloud dashboard cards to the stack entity page.
- Project Team Folders via Nextcloud app `scs_manager_integration` (stable `machineName` = Keycloak group id, editable label as mount point).
- Default project label **Project 1** / **Projekt 1** on first user provisioning, with Keycloak attributes `gid`, `label`, `nextcloudTeamFolder`, and `containedApps` placeholder.
- Follow-up plan: `docs/plans/project-centric-services-followup.md` (Vorhaben, WissKI/DB/Jupyter/WebProtégé).
- Technical backfill guide for existing projects/Team Folders: `docs/technical/project-team-folder-backfill.md`.
- Drush command `soda_scs_manager:backfill-project-team-folders` to bring legacy projects up to Team Folder parity (Keycloak attrs, members, Nextcloud folder; optional `--grant-nc-access`).
- Keycloak `{machineName}-admin` and `{machineName}-user` groups for SQL and Triplestore components (create, delete, project member sync), matching WissKI.
- Restored theme `package.json` with npm `overrides` for locked transitive CSS tooling dependencies.
- Configurable `snapshotHostPath` setting (and `soda_scs_manager.snapshot_host_path` in settings.php) for Portainer host bind mounts.
- Nextcloud settings field for OCC Docker container name (`occContainerName`).
- `LICENSE.txt` (GPL-2.0-or-later) and Drupal.org project page copy (`docs/drupal-org-project-page.md`).

- Nextcloud app passwords are stored encrypted in Drupal user data; Keycloak keeps only `nextcloud_login_name` (legacy Keycloak app-password attributes are migrated and cleared on read/connect).
- Nextcloud preview loads SCS-Share activity via `scs_manager_integration` (platform share `externalProjectId=scs-platform-share`) instead of the global Activity API path filter.
- Project create/edit/delete sync Nextcloud Team Folders and Keycloak group labels (group name remains the integer id).
- Snapshot manifests and Keycloak approval emails use the current site URL instead of a hardcoded production domain.
- SQL snapshot/restore Docker exec uses the configured `dbHost` container name.
- Interface translation server pattern points at `modules/contrib/`; composer metadata aligned with module dependencies.
- Settings UI / schema examples use `example.com` placeholders.

- Site content export zip, tmp config stubs, xdebug helper scripts, and dummy `assets/options` API drafts from the packaged tree.

- Nextcloud app passwords no longer remain as plaintext Keycloak user attributes after connect/migration.
- Pin transitive npm packages against Dependabot advisories: `nanoid` 3.3.17, `svgo` 4.0.2, `postcss` 8.5.26, `picomatch` 2.3.2 / 4.0.5.

1.0.0

1.0.0: Full snapshot create and restore

1.1.0

1.1.0: Health status and project member notifications

1.2.0

1.2.0: Version entities and automated single-instance updates

1.3.0

1.3.0: Multi-service dashboard health and issue reporting

2.0.0

2.0.0: Breaking project/filesystem model; Nextcloud connection

2.1.0

2.1.0: Onboarding wizard and UI polish

2.2.0

2.2.0: WissKI owner/member permissions and invitations

2.3.0

2.3.0: Keycloak attribute sync and account cleanup

2.4.0

2.4.0: Theme CSS move and project tag filtering