* fix: improve contrast on file name/extension in editor topbar
The file name and extension shown in the topbar when a file is open
were rendered in white on top of a light brand-colored background in
the vault Light Theme, and fell back to the same failing combination
in the vault Dark Theme - High Contrast (where the color was left
unset). Both now use a dark color that reads correctly against that
background.
* fix: improve contrast on share role dropdown hover text
The share permission dropdown's role options (e.g. "Can view",
"Can edit") rendered their hovered text in a color too close in
lightness to the hover background in the vault Dark Theme,
producing insufficient contrast. Lightened the color slightly to
restore adequate contrast without affecting its other uses.
* fix: improve low contrast on disabled danger buttons
Disabled danger-filled buttons had insufficient contrast between their
label text and background, caused by a disabled-state opacity fade
fighting against the muted background color. Danger buttons now keep
full opacity when disabled and use a darker muted background.
* feat(web): add mermaid-editor app for standalone .mmd diagrams
md-editor-v3's mermaid support only fires inside a Markdown fenced
code block, so there was no way to edit a Mermaid diagram on its own.
This adds a dedicated split-pane editor/preview app (mirroring
web-app-html-editor's shape) for the mmd/mermaid extensions, feeding
raw diagram source straight into mermaid.render() - no Markdown
wrapping involved. Invalid syntax surfaces an inline error instead of
crashing the preview pane, and the rendered SVG is sanitized with
DOMPurify the same way the embedded markdown-mermaid renderer already
does.
🤖 Generated with Claude Code
Signed-off-by: David Walter <david.walter@kiteworks.com>
* test(web): add e2e coverage and WCAG 2.2 checks for mermaid-editor
Wires the new 'mmdFile' resource type into the create/edit e2e
resource helpers (mirroring txtFile/mdFile) and adds a spec covering
diagram rendering, invalid-syntax error surfacing, and the view-mode
toggle. The new mermaidEditor.ts page-object asserts the existing
WCAG 2.1 a11y baseline every other e2e spec uses, plus an additional
WCAG 2.2 tag scan (target-size, focus-appearance, etc.) scoped to
this file only - the shared a11y helper used by every other spec
stays on its current WCAG 2.1 tag set, since widening it repo-wide is
a separate decision with its own pre-existing-violation triage cost.
🤖 Generated with Claude Code
Signed-off-by: David Walter <david.walter@kiteworks.com>
* fix(web): register mermaid-editor in the default enabled apps list
CI's e2e run for the new mermaid-editor app timed out waiting for the
"New > Mermaid diagram" menu entry: config.json.dist (a reference/dev
file) had "mermaid-editor" added, but the actual runtime default config
a packaged oCIS binary serves comes from services/web's Go defaults,
which didn't. Also runs Prettier over the 3 files check:format flagged.
🤖 Generated with Claude Code
Signed-off-by: David Walter <david.walter@kiteworks.com>
* fix(web): correct vue3-gettext version, add changelog entry
vue3-gettext was pinned to an exact "2.4.0" in web-app-mermaid-editor's
package.json (a copy-paste slip) instead of "^4.0.1" like every other
web app package, pulling in a stray v2 dependency tree with its own
deprecated transitives (glob@7.2.3, inflight@1.0.6). Also adds the
changelog/unreleased entry this PR was missing.
🤖 Generated with Claude Code
Signed-off-by: David Walter <david.walter@kiteworks.com>
* fix(web): resolve stale mermaid lockfile entry from merge conflict
web/pnpm-lock.yaml pinned mermaid to 11.16.0 for the new
web-app-mermaid-editor importer, left over from a badly-resolved merge
with master (which resolves mermaid to 11.16.1 in every other
importer and in the packages snapshot). pnpm install --frozen-lockfile
failed in CI with ERR_PNPM_LOCKFILE_MISSING_DEPENDENCY since 11.16.0
had no corresponding packages entry.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Signed-off-by: dj4oC <david.walter@kiteworks.com>
* test(web): register mermaid-editor in the e2e CI oCIS config
tests/config/ci/ocis-config.json is the WEB_UI_CONFIG_FILE the e2e
docker-compose stack (tests/acceptance/docker/src/ocis-base.yml) feeds
the oCIS instance under test. It keeps its own "apps" allowlist,
separate from services/web's Go defaults (already fixed) and
config.json.dist (also already fixed) - and it never got
"mermaid-editor" added. Without it, the running instance never
registers the app, so the "New > Mermaid diagram" menu entry the
mermaidEditor.spec.ts e2e test waits for never renders, and the click
times out after all retries.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Signed-off-by: dj4oC <david.walter@kiteworks.com>
* fix(web): give the mermaid-editor CodeMirror pane an accessible name
The plain-text CodeMirror content div renders with role="textbox"
aria-multiline="true" but no aria-label/aria-labelledby/title, which
axe-core (and screen readers) flag as a serious WCAG violation - this
is exactly what the e2e a11y scan caught on the new mermaidEditor
spec. Fixed via EditorView.contentAttributes, the same mechanism
CodeMirror exposes for this. MermaidEditorPane.spec.ts is updated to
install defaultPlugins() like its sibling specs already do, since the
component now calls useGettext() for the label text.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Signed-off-by: dj4oC <david.walter@kiteworks.com>
---------
Signed-off-by: David Walter <david.walter@kiteworks.com>
Signed-off-by: dj4oC <david.walter@kiteworks.com>
Co-authored-by: Claude Sonnet 5 <noreply@anthropic.com>
* feat: [OCISDEV-115] colour tag chips by tag name
Tag chips were all the same grey, so a file's tags were hard to tell apart
at a glance and the same tag looked like nothing in particular across the app.
Fill each chip with a colour derived from the tag name: `hash(tag) % length`
picks a slot in the theme's new `designTokens.tagColorsList`, emitted as
`--oc-color-tag-N`. The colour is derived, never stored, so a tag looks the
same for every user on every device with no API, storage or migration change.
The label colour is computed per fill rather than pinned to a token: the
fills come from the theme, so one token cannot stay legible against all of
them, and `--oc-color-text-inverse` gets it backwards in the light theme. The
calculation lives in `useTagColor` rather than in `OcTag` because the theme
store is a reactive dependency and `getComputedStyle` is not — resolving it
in the component would leave the label stale after a theme switch. The fill
is read straight out of `tagColorsList` rather than from the emitted css var,
since `getHexFromCssVar` reports an unresolvable var as `#000000` and would
hand a pale fill an illegible white label.
A filled chip carries `oc-tag-filled`, which forces the colours of everything
nested inside it down as `inherit`/`currentColor`. Those nested elements
otherwise repaint themselves — a `router-link` takes the global anchor colour,
a raw `OcButton` its own swatch, `.oc-tag .oc-icon > svg` a muted fill —
which left navy labels and a washed-out close icon on the deep light-theme
fills, and labels that were too light on the pale dark-theme ones. Nothing
hardcodes a colour, so both themes are covered by construction.
`OcTag` keeps its default appearance: it is the generic badge (the app-store
"most recent" pill, instance badges, the disabled-space indicator, the `+N`
counter), so both `fillColor` and `labelColor` are opt-in.
`initializeThemes` now merges with replace semantics for arrays. deepmerge
concatenates by default, which would turn a `tagColorsList` present in both
`defaults` and a theme into 60 entries and shift every hue.
Also make the tag overflow indicator on the files list a real, keyboard
reachable button that shows the hidden tags in a popover instead of opening
the sidebar. That popover is sized to its tags: `OcDrop` is a fixed 300px
wide, which left it nearly empty when it held a single chip capped at 80px by
`.resource-table-tag`, with the right alignment the tags column passes down
pushing that chip to the far edge. 300px is kept only as a cap so a long tag
still truncates.
Both `theme.json` copies gain 30 placeholder fills per theme, per theme
rather than in `defaults`, so the feature can be exercised end to end while
design's real values are outstanding. They were generated by binary-searching
HSL lightness for a target relative luminance per hue, since equal-lightness
hues differ a lot in perceived brightness: deep fills with white labels in
the light themes, pale fills with black labels in the dark ones. Worst-case
label contrast is 6.31:1 (light) and 8.52:1 (dark), higher in both
high-contrast themes. Both copies are needed — web-runtime's file is what
`pnpm build` publishes to `web/dist/themes`, while an ocis binary serves the
go:embed-ed `services/web/assets/themes` copy instead
(services/web/pkg/server/http/server.go layers it over the embedded core
assets). Every theme in a file has the same list length, so a tag keeps its
colour slot across a theme switch.
* feat: add ownCloud branding background to login screens
Ships the ownCloud branding image as the default IDP login background and
aligns the web and Keycloak login screens to match.
Reworked for the no-npm IDP (services/idp/src was removed by #12086): the
branding is applied directly in the committed bundle. The default background
image lives at services/idp/assets/identifier/static/media and is referenced
from theme.css, which now anchors it to the top right (background-position) so
the ownCloud logo stays fully visible at every viewport aspect ratio instead
of being cropped by center positioning. Operators can still override the image
via IDP_LOGIN_BACKGROUND_URL (unchanged on master).
Also embeds the same image in the web service theme assets and adds an
"owncloud" Keycloak login theme (already anchored top right) to the
ocis_keycloak deployment example.
Signed-off-by: David Walter <david.walter@kiteworks.com>
Signed-off-by: Lukas Hirt <info@hirt.cz>
* docs(deployment): title-case ocis_keycloak README headings
Co-authored-by: Martin <github@diemattels.at>
Signed-off-by: Lukas Hirt <info@hirt.cz>
---------
Signed-off-by: David Walter <david.walter@kiteworks.com>
Signed-off-by: Lukas Hirt <info@hirt.cz>
Co-authored-by: kobergj <jkoberg@owncloud.com>
Co-authored-by: Martin <github@diemattels.at>
A theme can define its own logo per UI variant under
clients.web.themes[].logo, including the built-in "owncloud" theme, most
of whose variants (dark, high contrast, ...) already do this. The admin
logo upload endpoint only ever patched clients.web.defaults.logo, so the
active theme's own per-variant logo kept winning over a logo an admin
explicitly uploaded through the admin settings web app.
Force the branding (admin-uploaded) logo onto every theme variant's own
logo entries after the theme merge, so it always takes precedence.
Signed-off-by: Lukas Hirt <info@hirt.cz>
* fix(web): generate web timestamp by env SOURCE_DATE_EPOCH or git log (#12757)
* fix(web): suppress error when make in non-git directory (e.g. source tarballs)
* chore: add changelog for pull 12758
* fix(web): fix env description in changelog; remove cwd from execSync
* fix(web): fix format (prettier check)
Fixes low-contrast sliders, switches, select highlights, and the global
search input/placeholder, including an !important override that blocked
theme-specific search colors and an invalid CSS var() fallback.
The Light/Dark High-Contrast themes set colorPalette.background-highlight
equal to background-default, making hover backgrounds indistinguishable
from the resting page background wherever background-highlight was used
for interactive feedback (e.g. the global search results dropdown). The
non-high-contrast Dark theme had the same collision.
Set background-highlight to the same value as background-hover in those
theme blocks, and point SearchBar's result-preview hover/active state and
CreateShortcutModal's context-menu hover/active state at
--oc-color-background-hover directly, since background-highlight is
otherwise used for static surfaces (cards, modals, form fields) rather
than interaction feedback.
* chore: [OCISDEV-5] Merge and relicense ownCloud Web into oCIS
Consolidate the ownCloud Web frontend into this repository as a single
product with one contribution surface and one license. The web/ source
is imported as-is from the final standalone owncloud/web release
(v12.5.0 / last-agpl-release @ b16a34fdf5569d2fd63b1ff3c575c1a4ee569ad3);
the archived owncloud/web repository remains the historical record for
everything at and before that commit.
Relicensing:
- All web/ contributors have signed the ownCloud CLA, granting ownCloud
GmbH the right to relicense their contributions.
- web/LICENSE (AGPL-3.0) removed; the repository root LICENSE
(Apache-2.0) now governs web/ as well, matching how the rest of the
repo is already licensed.
- All 25 web/packages/*/package.json license fields flipped to
Apache-2.0; root NOTICE added documenting the relicensing provenance.
- Added REUSE.toml + LICENSES/ so the whole repository (including
vendored Go dependencies) is REUSE 3.3 compliant.
CI/build:
- services/web/Makefile now builds web assets from the in-tree source
instead of downloading a release tarball from owncloud/web; license
checking/saving likewise runs against the in-tree source.
- ci.env and tests/acceptance/run-e2e.py no longer clone owncloud/web
for Playwright e2e tests.
- Added the app-provider and ocm e2e suites to acceptance-tests.yml's
matrix, closing a coverage gap where they were silently excluded;
ported the Collabora/OnlyOffice/federated-instance orchestration
web's old CI used to run them.
- Added web-tests.yml (typecheck/format/lint/unit-test), a
check-licenses.yml, commit-message.yml, and release-npm-packages.yml
for the @ownclouders/* packages, replacing web's old standalone CI.
- Removed dead CI tooling inherited from the standalone repo
(web/tests/drone, web/tests/actions, web/.github, and an orphaned
ci.env-dependent cache-check script).
Docs:
- Rewrote docs/services/web/releasing.md and web/docs/releasing to
describe the in-tree build/release process.
- Updated remaining references to github.com/owncloud/web across docs,
services/web/README.md, and the deployment example to point at the
in-tree web/ directory.
Signed-off-by: Lukas Hirt <info@hirt.cz>
* ci: sync web/ translations via Transifex
web/ is a pnpm workspace nested inside the repo, so it isn't covered by
the existing translation-sync job (sub_path: ., no package.json at the
repo root). Add a second sync-web job invoking the same reusable
workflow with sub_path: web and package_manager: pnpm, so its l10n-read/
push/pull/write targets actually install web's dependencies instead of
silently running against an empty node_modules. Sequenced after the
existing sync job since both push to the same hardcoded
chore/translations-update branch.
* ci: fix pnpm cache setup order in web-tests and check-licenses
actions/setup-node's cache: pnpm input shells out to pnpm to resolve
the cache directory, so pnpm must already be on PATH when that step
runs. Both workflows ran `corepack enable` *after* setup-node, which
still failed: corepack writes its pnpm shim into the currently active
Node installation's bin dir, and setup-node had already swapped PATH
to the newly-installed Node version by that point, leaving the shim
behind. Use pnpm/action-setup instead, which installs a standalone
pnpm binary independent of the Node version, before setup-node runs.
Also set cache-dependency-path explicitly: the lockfile lives at
web/pnpm-lock.yaml, and cache-dependency-path resolves relative to
GITHUB_WORKSPACE regardless of the job's working-directory default
(that default only applies to run: steps, not to setup-node itself).
* fix(web): resolve 19 HIGH trivy findings in pnpm-lock.yaml
All 19 findings had fixes available upstream, so per this repo's own
.trivyignore policy (reserved for cases with no fix available), these
get fixed rather than suppressed.
vite (7.3.2 -> 7.3.5) is a direct dependency, bumped directly in every
package.json that pins it.
The other 8 (@xmldom/xmldom, flatted, form-data, immutable, js-cookie,
linkify-it, minimatch, ws) are purely transitive. Verified empirically
that `pnpm update <pkg>` silently no-ops on packages not declared in
any workspace manifest, even when a parent's semver range would allow
the fix (e.g. glob@10.5.0's `^9.0.4` covers 9.0.7) -- so pnpm.overrides
is genuinely required here, not just convenient.
minimatch is overridden with a version-range key
(minimatch@>=9.0.0 <9.0.7) rather than a blanket override, since 6
different major versions of minimatch coexist in the tree for
different consumers (3.x/5.x/10.x elsewhere); a blanket override would
have forced all of them to 9.0.7 and likely broken callers expecting a
different major's API.
* fix(web): unify @types/node resolution to stop duplicate vite types
The previous vite 7.3.2 -> 7.3.5 bump caused pnpm to resolve two
different @types/node versions (25.7.0 and 26.1.0) as vite's optional
peer across different workspace packages. vue-tsc then saw two
structurally-different copies of vite's types (e.g. Plugin, HotUpdateOptions)
and failed with TS2769 in design-system, web-client, web-pkg and
web-test-helpers' vite.config.ts files.
Force a single resolution via pnpm.overrides, pinned to 24.13.2 to
match the Node 24 runtime (engines/volta) rather than an arbitrary
newer major.
* fix(tests): fix ocm/app-provider e2e suites' oCIS orchestration
Both suites were newly wired up by the previous merge-web-repo commit
and hadn't run against real CI yet, so their setup had two latent bugs:
e2e-ocm: the federated instance's env only offset *_DEBUG_ADDR ports,
leaving the actual service ports (e.g. gateway's default
127.0.0.1:9142) unset. The federated "ocis server" process then
crashed trying to bind the same ports the primary instance already
held. run-github.py's Behat apiOcm suite already solved this with a
canonical tests/config/local/.env-federation port map (proven working,
since apiOcm passes) -- reuse it instead of the ad-hoc offset. Also
adds OCIS_ADD_RUN_SERVICES=ocm/OCIS_ENABLE_OCM, missing from the
primary instance too.
e2e-app-provider: tests/config/ci/app-registry.yaml maps its one
mimetype to "FakeOffice" (the stub used by apiCollaboration) and has
no docx entry at all, so the real Collabora/OnlyOffice containers this
suite drives never appeared in the web UI's "New file" menu. Add a
dedicated app-registry mapping both odt->Collabora and docx->OnlyOffice
with allow_creation, and use it only when COLLABORATION_NEEDED is set.
Signed-off-by: Lukas Hirt <info@hirt.cz>
* fix(tests): trust federated oCIS cert, register office templates by target_ext
e2e-ocm: the primary and federated instances each generate their own
self-signed proxy cert. Only the primary's was ever added to the
system CA trust store, so Chromium refused the federated instance's
TLS handshake ("tls: unknown certificate") once federation began.
Trust the federated cert too, and thread OCIS_BASE_DATA_PATH through
its `ocis init` call (previously only set for the running server),
since that's where the cert actually gets written.
e2e-app-provider: reproduced the suite locally (real Collabora/
OnlyOffice containers + `ocis collaboration server`) and diffed
`/app/list` before/after. allow_creation and default_app alone don't
make the web UI's "New file" menu show an entry -- it additionally
requires app_providers[].target_ext, which reva's app-provider only
stamps onto a hardcoded set of "-template" mimetypes
(vendor/github.com/owncloud/reva/v2/.../appprovider/templates.go), not
the plain document mimetypes the previous config used. Existing odt/
docx files still open fine without a static entry, since Collabora/
OnlyOffice register their full supported mimetype list dynamically via
WOPI discovery -- it's specifically file *creation* that needs this.
Signed-off-by: Lukas Hirt <info@hirt.cz>
* fix(changelog): shorten title over the 80-char lint limit
changelog/unreleased/bugfix-personal-space-fail-closed.md landed on
master (#12442) with a 97-char title, which changelog-lint rejects.
GitHub tests PRs against a merge with the current master tip, so this
started failing build-and-test on every open PR once master picked up
that commit -- unrelated to this branch's own changes. Fixing it here
since master needed to be merged in anyway.
* fix(tests): load web apps the ocm/app-provider e2e suites depend on
Both suites drive the web UI, and web only loads the web apps listed in
its UI config's "apps" array. run-e2e.py reuses
tests/config/ci/ocis-config.json, which predates the playwright suites
and lists neither app they need, so both failed deterministically while
the API-only Behat suites (apiOcm, apiCollaboration) kept passing:
e2e-ocm: the "open-cloud-mesh" app menu item can never render because
"ocm" was missing, so web-app-ocm was never loaded. Add it for the
federated suite. Behind that sat a second bug: the invite flow embeds
token@<BASE_URL_OCIS host> (127.0.0.1:9200) into invite codes, but the
federated instance authorizes providers against
tests/config/local/providers.json, which only lists localhost:9200.
Address the primary as https://localhost:9200 when federated, mirroring
run-github.py's passing apiOcm setup (the self-signed cert covers both
hosts; other suites keep 127.0.0.1).
e2e-app-provider: web-runtime only builds the per-provider Collabora/
OnlyOffice editor apps -- including their "New file" menu entries --
when web-app-external is loaded (web/packages/web-runtime/src/index.ts
gates on applicationStore.has('web-app-external')), and "external" was
missing. This also falsifies the previous target_ext theory: the
template-mimetype registry was active in the failing run and the menu
still never appeared, because the New-file menu needs only
allow_creation plus a registered provider
(web-app-external/src/index.ts). Revert the app registry to the plain
odt->Collabora / docx->OnlyOffice mimetypes web's own e2e CI proved out
(web/dev/docker/ocis/app-registry.yaml). Create-from-template still
works without static entries: reva stamps target_ext onto the -template
mimetypes the providers register via WOPI discovery.
Signed-off-by: Lukas Hirt <info@hirt.cz>
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
* ci: upload playwright traces and a11y report from e2e suites
Port the two upload-artifact steps the standalone web repo's e2e
workflow had: playwright error contexts/report output on failure, and
the a11y report on any non-cancelled run. Paths are prefixed with web/
since the web repo now lives in that subdirectory, artifact names use
the suite name instead of the job index, and the action pin matches the
one already used in this workflow.
Signed-off-by: Lukas Hirt <info@hirt.cz>
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
* fix(tests): allow office editor iframes in the e2e proxy CSP
The app-provider suite got past file creation but every office test
then timed out waiting for the editor to render: ocis's default proxy
CSP only allows frame-src 'self' (exact scheme+host+port), so the
browser refused to embed the Collabora/OnlyOffice iframes served on
other ports. The COLLABORA_DOMAIN/ONLYOFFICE_DOMAIN env vars do nothing
on their own -- they are only substituted into a custom CSP file, which
is why the pre-merge web CI always set PROXY_CSP_CONFIG_FILE_LOCATION
(tests/drone/csp.yaml there). The localStorage SecurityError seen in
the logs was a downstream symptom: the CSP-blocked frame ends up with
an opaque origin where storage access throws.
Add the two editor domains to tests/config/ci/csp.yaml's frame-src and
img-src (mirroring web's proven csp.yaml) and point the collaboration
suite at it. The keycloak suite shares this file; for it the new
entries fall back to nonexistent default hosts and are inert.
Signed-off-by: Lukas Hirt <info@hirt.cz>
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
* fix(licenses): attribute REUSE.toml copyright to ownCloud contributors
The web/ tree carries community contributions dating back to 2016; the
CLA grants a relicensing right, not a copyright transfer, so declaring
sole 2020-2026 ownCloud GmbH authorship was inaccurate.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
* fix(tests): trust the Keycloak cert in e2e TLS setup
The Keycloak cert had no SAN, and NODE_EXTRA_CA_CERTS only ever pointed
at the oCIS cert, so any node-fetch/axios call made directly against
Keycloak (admin token fetch, user provisioning) failed TLS validation
and aborted the keycloak/mfa matrix jobs before a spec could run.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
* fix(web): don't wipe assets/ before a successful build
build-assets ran `git clean -xfd assets` before the pnpm build; a failed
typecheck or vite build left assets/core/ empty, so the next Go embed or
docker deployment served no web UI. Clean only after the build succeeds.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
* ci: fail clearly when a release tag matches no known package
If the tag-prefix loop found no match, the workflow silently fell
through to a jq lookup against "packages//package.json", failing with a
confusing path error instead of naming the problem.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
* ci: drop duplicate dependency-license-check job
web-tests.yml already enforces the license allow-list via
`pnpm licenses:check` (license-checker-rseidelsohn) on every PR.
check-licenses.yml's dependency-license-check ran a second, differently
configured tool (npx license-checker, GPL/AGPL deny-list only), which
could disagree with the first without adding coverage.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
---------
Signed-off-by: Lukas Hirt <info@hirt.cz>
Co-authored-by: Claude Fable 5 <noreply@anthropic.com>
Change the primary swatch hover color to slightly darker one to improve contrast on white background.
This change affects only the default light theme.
Added necessary keys into the ownCloud theme to support universal access.
Their values are empty strings so that the universal access is hidden in the UI by default.
otelchi and other custom solutions have been replaced with otelhttp to
trace HTTP requests; new middleware is provided to be used across the
platform.
The proxy service will use a custom HTTP client to forward the headers
needed for telemetry automatically (also based on otelhttp)
Added a new built-in role: `SpaceEditorWithoutTrashbin`.
This role is a subset of the `SpaceEditor` role, but it does not have list/restore resources in trashbin permissions.
