grommunio Web 5.0 in the lab: settings namespace, shared mailboxes and admin impact

grommunio Web 5.0 in the ForgeOne lab

This article is the technical deep dive for the grommunio Web 5 release. It separates vendor claims from behavior we actually checked in our own grommunio appliance. The relevant question was not only whether the new web client starts, but what the update means for shared mailboxes, automount scripts, administrators and real user workflows.

The short release note is separate: grommunio Web 5.0 released. This article stays deliberately technical.

Tested baseline

The test was performed on 17 September 2026 on an isolated grommunio Appliance 2026.06.1. Installed versions included grommunio Web 5.0.18.g733d827bd, Gromox 3.10.147.m6714105 and grommunio Admin API 1.21.14.m7efd177. Browser tests used Playwright Chromium, while websettings, packages, services, users, domains and folder permissions were checked via CLI.

The lab contained two domains, regular users, one shared mailbox and two additional test accounts for automount migration checks. Screenshots use test data only; secrets and internal paths are not shown in the public article.

Why Web 5 matters for administrators

grommunio Web 5 is not only a new interface. Operationally, three points matter most: the visible user experience changes with Command Palette, shortcut view and a more modern theme; shared-mailbox workflows still need to work reliably; and the settings namespace moves away from historic zarafa naming toward grommunio/v1.

The third point affects automation. Many older notes and scripts read or write settings.zarafa.v1.contexts.hierarchy.shared_stores. In Web 5, new automounts should target settings.grommunio.v1.contexts.hierarchy.shared_stores.

Command Palette and daily handling

The Command Palette was available in the lab via Ctrl+K. It could open settings and appearance actions. For power users, this matters because grommunio Web can be operated more like a desktop application.

Settings, version and undo/redo

The settings page showed grommunio Web 5.0.18.g733d827bd, Gromox 3.10.147.m6714105, Basic Authentication and the Chromium browser used for the test. The undo/redo option for message actions was visible. We still classify undo/redo as partial because a reliable delete/move/undo transaction was not completed in the headless run.

Shared mailboxes and folder permissions

The shared mailbox shared-folders@example-a.test was displayed in grommunio Web. Alice saw Finance, Bob saw Sales and Projects. Folders that were not delegated were not visible in the respective user context. This confirms the most important productive path for mounted shared mailboxes in the web client.

The separate step-by-step guide for using a shared mailbox as a public-folder replacement is linked here: grommunio shared mailbox instead of public folders.

Automount: from zarafa/v1 to grommunio/v1

The deep dive checked four automount cases. Existing users with migrated settings had only grommunio/v1. One new test user deliberately received only the old zarafa/v1 path before first Web 5 login. After login, the shared store was visible and the websettings were stored under grommunio/v1. Another test user received the shared store directly under grommunio/v1; that path worked as well.

The operational conclusion is important: Web 5 accepted the old path in the lab and migrated it, but new automation should no longer write zarafa/v1. The current target path is grommunio/v1.

{
  "settings": {
    "grommunio": {
      "v1": {
        "contexts": {
          "hierarchy": {
            "shared_stores": {
              "7368617265642d666f6c64657273406578616d706c652d612e74657374": {
                "all": {
                  "folder_type": "all",
                  "show_subfolders": true
                }
              }
            }
          }
        }
      }
    }
  }
}

Custom automount scripts should therefore handle both worlds deliberately: read or migrate existing zarafa/v1 settings, but write new entries under grommunio/v1.

#!/bin/bash
set -euo pipefail

WEB_USER="alice@example-a.test"
SHARED_MAILBOX="shared-folders@example-a.test"
SHARED_ID="$(printf '%s' "$SHARED_MAILBOX" | xxd -p -c 256)"

SETTINGS="$(gromox-mbop -u "$WEB_USER" get-websettings)"
UPDATED="$(printf '%s' "$SETTINGS" | jq --arg id "$SHARED_ID" '
  .settings //= {}
  | .settings.grommunio //= {}
  | .settings.grommunio.v1 //= {}
  | .settings.grommunio.v1.contexts //= {}
  | .settings.grommunio.v1.contexts.hierarchy //= {}
  | .settings.grommunio.v1.contexts.hierarchy.shared_stores //= {}
  | .settings.grommunio.v1.contexts.hierarchy.shared_stores[$id] = {
      "all": {
        "folder_type": "all",
        "show_subfolders": true
      }
    }
')"

printf '%s' "$UPDATED" | gromox-mbop -u "$WEB_USER" set-websettings

Search, categories, attachments and document viewer

For search, categories, attachments and the document viewer we created test data, but deliberately do not mark every path as fully accepted. Test messages and attachments existed server-side. The web search showed fields, filters and search state in the browser, but did not produce a reproducible result list in the headless run. That is PARTIAL, not PASS.

Categories were only probed in the web context; complete Outlook and mobile synchronization was not part of this acceptance run. Attachments were created as a message with PDF, DOCX, XLSX, PPTX, CSV, Markdown, JSON and PNG files, but multi-select, save, remove and document viewer behavior were not fully clicked through. OpenPGP was not tested.

Technical acceptance

The result check follows the standardized grommunio format. PASS means that the concrete check was executed and evidenced in the lab. PARTIAL and NOT TESTED remain visible where no complete end-to-end evidence exists.

Upgrade checklist for administrators

Before rollout, treat Web 5 as a client update with operational consequences. Check package versions, back up websettings, review shared-mailbox automounts, adjust custom scripts to grommunio/v1, test role and folder visibility with real user profiles, and accept search, attachments, categories, document viewer, OpenPGP and notifications separately.

For plugins, themes and customer-specific extensions, also check for obsolete Zarafa naming, old asset paths or DOM assumptions.

What we do not count as fully tested

This run did not fully accept OpenPGP with real test keys, desktop notifications, all document viewer formats, attachment multi-actions, full category synchronization with Outlook and mobile clients, or search performance over large production-like mailboxes. These items belong in separate customer acceptance tests before they are treated as production-ready for a specific environment.

Conclusion

grommunio Web 5.0 worked in the ForgeOne lab as a modern web client with visible Command Palette, dark mode, shared-mailbox visibility and grommunio/v1 settings. The most important technical finding is automount migration: old zarafa/v1 entries were still accepted and moved to grommunio/v1 in the lab, but new automation should consistently write grommunio/v1.

For production environments, Web 5 is therefore not just a cosmetic update. It is an update where usability, settings, shared-mailbox operations and custom automation have to be reviewed together.