feat: add Zammad ticket integration

[Optic00]

Summary

• Add administrator-managed Zammad connections using encrypted API tokens or the native OAuth flow.
• Reuse Windshift's integration-provider, action-credential, workspace-scope, OAuth, and item-link infrastructure. Zammad-specific ticket policy and synchronization remain typed provider data.
• Create new tickets or link existing ones from Windshift items, with durable mappings, group scoping, correlation-based duplicate protection, polling, manual refresh, owner/group/state updates, and optional closed-state workflow mapping.
• Persist the administrator-approved Zammad group catalog as {id, name} pairs. Runtime operations verify live ticket and group IDs without calling Zammad's admin-only groups endpoint.
• Add permission-checked return links from Zammad to the current Windshift item, plus setup and operating documentation.

Safety and recovery

• Harden outbound requests with the existing public-address SSRF policy, redirect checks, bounded responses, and sanitized errors.
• Preserve existing Zammad configuration during upgrade and backfill canonical workspace scopes only for managed Zammad credentials.
• Guard item, workspace, and user lifecycle operations through provider-neutral integration-link checks.
• Provide an audited, administrator-only local detach path for recovery when a remote Zammad ticket is unavailable.

Scope

This implements the core integration proposed in #234. Comment and attachment synchronization, arbitrary field synchronization, webhooks, and the optional workspace dashboard remain out of scope.

Validation

• go test ./...
• Frontend: npm run check, npm run typecheck, npm run test:run, npm run build
• Container build with the repository-pinned Node and Go toolchains
• Upgrade and manual end-to-end use in an isolated Zammad/Windshift lab: connection test, single-ticket refresh, system-wide refresh, and links in both directions

The integration has only been tested in the lab, not in production. The existing OAuth connection remained operational after the upgrade, but OAuth authorization itself was not repeated in the final pass. Zammad is not yet part of the automated end-to-end suite.

[stefan-ernst]

Thank you!

One issue:

The setup guide says to grant only ticket.agent with
read/create/change group access and explicitly says not to grant
group administration: zammad-integration.md
(

core/docs/zammad-integration.md

Line 43 in 2aeb692

## Zammad service account and permissions

).

However, virtually every operation calls Client.Groups(), which
requests GET /api/v1/groups: client.go
(

core/internal/integrations/zammad/client.go

Line 89 in 2aeb692

func (c *Client) Metadata(ctx context.Context) (*models.ZammadConnectionMetadata, error) {

).
Zammad officially documents that endpoint as requiring admin.group:
Zammad Group API
(https://docs.zammad.org/en/latest/api/group.html).

Generally: Since we are mapping an entire zammad admin credential to the windshift integration, that means the integration is a bit unbalanced from a scaling perspective. I believe it will work for small teams, so we can merge it with this architecture with one caveat: We should extend the existing integration system to support this instead of building a parallel one

[Optic00]

Thanks, you are right on both points. The /groups dependency is a real authorization bug, not a documentation issue. It is currently reached by connection testing, ticket creation, linking, updates and every polling cycle, while Zammad requires admin.group. I do not want to solve that by broadening the credential permissions.

I propose removing /api/v1/groups from all runtime paths. Configured groups will be stored as {id, name}, validated against /api/v1/users/me and its group_ids, and ticket synchronization will validate the ticket's own group_id. I will verify group_id support during ticket creation and /users/search access with the restricted service account in the lab.

I also agree with extending the existing integration system. The PR already reuses integration_providers, action_credentials and item_integration_links, but connection ownership, OAuth, workspace scoping and core link guards still diverge.

My proposed boundary is a common provider/connection layer supporting both user-owned and system-owned credentials, API tokens and OAuth, workspace scopes and provider capabilities. Zammad-specific ticket policy and synchronization remain a typed provider sidecar. I would also replace the direct Zammad dependencies in deletion, move and offboarding paths with a generic link policy.

Since none of this schema has been released yet, I would prefer correcting that structure in this PR instead of shipping parallel lifecycle tables. Does that match what you had in mind?

[github-actions]

This PR has merge conflicts that need to be resolved before it can be merged. Please rebase on the latest main branch.