OM-17/15: Google Workspace plugin manifest needs format validation, German labels, and prerequisites on the card

[Weegy]

Follow-up from the first customer test report (PR #599). Findings OM-17 (high) and OM-15. Cross-repo: the fix does not live in byte5ai/omadia.

What happened

The tester installed the Google Workspace plugin, saw an email field with a masked field directly beneath it, and entered their work email address and their actual Google account password. The system accepted both silently and confirmed "gespeichert". The fields meant gw_sa_client_email and gw_sa_private_key — two values out of a Google Cloud service-account JSON key file.

Their own words:

"Ich arbeite seit Monaten täglich mit KI-Werkzeugen und Systemkonfiguration. Wenn ich an dieser Stelle ein Login sehe, dann ist das kein Anwenderfehler."

They are right. omadia never asks for a Google password; the documented path is correct and secure. This is purely a design failure. The tester removed the values the same evening and rotated the account password.

What PR #599 already shipped (platform half, benefits every plugin)

• A standing caution under every type: secret input: "Hier gehört kein Konto-Passwort hinein." Manifest-independent — this alone would have prevented the finding.
• pattern + pattern_hint (localised) in the manifest schema, parsed by manifestLoader, enforced server-side in every write path — PATCH /v1/admin/runtime/installed/:id/secrets previously validated only the shape, never the value.
• Patterns are anchored to match HTML pattern= semantics, screened by an allowlist grammar at load, and every match runs in a worker under a 50 ms budget (manifests are untrusted input).
• The manifest placeholder is finally honoured — it was parsed and then discarded by both renderers.

What is still needed — and where

The Google Workspace plugin manifest is in neither this repo nor omadia-byte5-plugins. Greps for gw_sa_client_email / gw_sa_private_key return nothing in either tree; the plugin is published separately via hub.omadia.ai. Locate that repo first — that is task zero.

Then, in the plugin manifest:

1. pattern + pattern_hint on both fields:
   • gw_sa_client_email → expects …@….iam.gserviceaccount.com
   • gw_sa_private_key → expects a PEM block starting with -----BEGIN PRIVATE KEY-----
2. German label and help for every setup field. Today the "Beschreibung" section is entirely English while the instructions directly below it are German — two languages on one page. Note the schema asymmetry: setup_guide is already LocalizedMarkdown, but label / help / description are plain strings (see the linked platform issue).
3. OM-15 — prerequisites on the card, before install. Setup requires a Google Cloud service account with domain-wide delegation, seven individual APIs enabled, splitting a JSON key file, and super-admin rights in the Workspace admin console. The tester's reaction on reading it: "Auch wenn die Beschreibung nicht danach klingt, als würde ich es hinbekommen." — and they only found out after installing. Mark it on the tile: "Einrichtung durch IT-Administrator · ca. 15 Min · Google-Workspace-Super-Admin erforderlich". This needs a new manifest block plus hub republication.
4. A benefit-oriented opening sentence in plain language, technical detail collapsed under "Für Entwickler".

Mid-term, the structurally correct fix is a guided OAuth flow instead of manual service-account setup.

OM-17 is not closed for this customer until step 1 ships. The standing caution protects users today regardless.

[Weegy]

Repo located — it is byte5ai/omadia-google-workspace, checked out at ~/sources/omadia-google-workspace. My earlier grep only covered odoo-bot and omadia-byte5-plugins, hence the "not in either repo" note in the original issue.

The pattern / pattern_hint half is done: byte5ai/omadia-google-workspace#1.

Covers all four fields that take an address or a key, with localized (en/de) hints. Verified against the actual platform loader rather than testing regexes in isolation: all four accepted by the allowlist, refused-pattern registry empty, both values the tester actually typed (s.lange@te-printline.de, a plain password) rejected with the German hint, real PEM blocks accepted, empty values still clearable, and the packaged manifest inside the built zip carries everything.

Still open in this issue

• OM-15 prerequisites on the card — needs a new manifest block the platform does not support yet ("Setup by IT administrator · ~15 min · Google Workspace super-admin required").
• German label / help — blocked platform-side: those are typed as plain string, while setup_guide and (as of fix: honest status reporting, routines crash, and setup-field safety #599) pattern_hint are LocalizedMarkdown. This is the schema asymmetry noted in the original issue; it needs a LocalizedText migration touching the manifest schema, loader, codegen, both renderers, and every published plugin.

Two platform defects found while doing this — both filed in #605

1. The allowlist refuses {n,} while allowing +, which is equivalent. The first realistic pattern written against this feature ([A-Za-z]{2,} for a TLD) was rejected for no safety reason.
2. The server's 400 runtime.setup_field_invalid always returns the English hint — checkSetupFieldPattern(field, value, context, locale = 'en') and runtime.ts never passes a locale. The client-side pre-submit check localizes correctly, so this only bites on the server fallback path — but "English help text in a German UI" was one of the named contributing factors of OM-17 itself.