Proposal: Zammad ticket integration

[Optic00]

Would a native Zammad integration be welcome in the open-source core? I have a working local prototype, but before turning it into a PR I would like to align on architecture and scope.

Proposed MVP:

• An explicit action from an item creates a Zammad ticket in a configured, allowed group.
• Durable mapping plus search-before-create reduces duplicate risk. Ambiguous POST outcomes remain search-only until an administrator explicitly allows another creation attempt.
• Polling refreshes the ticket status shown on the item and can optionally trigger a transition through the existing workflow service.
• API tokens are encrypted and connections can be restricted to selected workspaces.
• No bidirectional field, comment, or attachment sync and no webhooks initially.

The prototype reuses the existing integration provider, external-link, credential, permission, and workflow infrastructure while adding provider-specific persistence and API/UI surfaces. Automated backend, frontend, and schema checks pass, but neither Zammad nor PostgreSQL has been exercised live yet.

Questions:

1. Is this integration desirable in the open-source core?
2. Would you prefer a dedicated provider or a more generic external ticket-system abstraction?
3. Is polling acceptable for the MVP, or should the design start with webhooks?
4. Would you prefer one full-stack PR or smaller backend and UI changes?
5. Which Zammad versions and live-test evidence would you expect before review or merge?

If the direction fits, I am happy to live-test it and open a draft PR.

[stefan-ernst]

Hey @Optic00 - yes that will totally work, I dont see a reason not to do it

A couple of questions on the design:

• We might have some functional overlap between Zammad and Windshift, we need to signal where that integration makes sense
• Bidirectional Comment sync will probably be requested very soon if this goes live, so we need to account for it - unless we design the integration to hand-off a ticket and only sync back the status to Zammad, what do you think?
• Is a Zammad side functional change necessary, what happens if they dont accept it in the upstream? Any existing integrations that we coud use as a blue print, for example Jira?
• Using the native oauth provider interface would be best. Functional extensions there are welcome to accommodate additional integrations, feel free to submit those
• Polling is acceptable
• Lets do a full PR, we can discuss everything in one piece
• I can install Zammad and we can even possibly integrate it in the test suite to do a complete end-to-end test.

I am currently finishing up publishing the core-tests repo so bigger PRs can be properly tested

[Optic00]

Thanks. #238 follows the functional boundaries, with one open OAuth question.

• Responsibility split: Windshift owns planning and the internal work item. Zammad owns intake, communication, routing, SLAs, and resolution. Windshift observes state, group, and owner and permits explicit updates, but does not mirror the ticket.
• Comments: The item description becomes the initial internal Zammad note. There is no later comment or attachment sync. Bidirectional sync needs a separate design for article visibility, identities, permissions, edits, attachments, and loop prevention. I would start with an explicit "send update to Zammad" action.
• Zammad dependency: No Zammad source change or plugin is required. The standard REST API, a restricted service account, and an administrator-created text attribute provide correlation and duplicate protection. The field can use Zammad's standard link template for the return link. The Jira integration is import-oriented and not a direct blueprint.
• OAuth: feat: add Zammad ticket integration #238 implements Zammad's authorization-code flow, but does not extend Windshift's IntegrationOAuthHandler, currently limited to per-user Notion/Todoist connections. Zammad uses administrator-owned provider records and encrypted credentials. If the common interface should cover system-owned connections, I can refactor this before merge.
• Polling/testing: Polling runs two minutes after each completed run, with manual refresh for one or all tickets. It has been tested in a private lab against Zammad 7.1.1 with PostgreSQL, but not in production. I am happy to add a Zammad-backed core-tests scenario.

Does that split and the proposed OAuth boundary match what you had in mind?