Proposal & roadmap: contributing ticketing, CRM, RBAC, SLA & content-visibility as a reviewable 10-PR stack

[melihsunbul]

Proposal & roadmap: contributing ticketing, CRM, RBAC, SLA and content-visibility

Who we are

We are Excellence Cloud GmbH. I am the manager of the company, and I personally developed all of the pull requests in this proposal. We have been building on Quackback and would like to contribute the work back, in close coordination with you, rather than carry it as a long-lived fork.

Why we are doing this

We chose Quackback deliberately. We wanted a foundation with strong baselines, clear documentation and a disciplined, high-quality maintenance process behind it — because we intend to use it at the centre of our own organisational processes, to combine internal and external communication and management on one platform. The engineering standard and the review discipline on this project are precisely why we want to build with it and not around it.

The honest consequence is that we have written a fair amount of new surface. We are aware this proposes a meaningful extension to the scope you may have had in mind for the project. We have tried to make it easy to take on:

• Additive, not invasive. Everything is layered on top of the existing model. The database changes are additive (new tables, nullable/defaulted columns); no existing table is reshaped destructively.
• Reuse over reinvention. New features publish through the existing event/dispatch, integration and permission patterns rather than introducing parallel mechanisms.
• Unify close concepts instead of duplicating them. Where a new idea sat close to an existing one, we merged rather than forked the mental model. The clearest example: instead of adding a competing "people" entity, the new Customers workspace unifies existing portal users with the new contacts and organisations, so there is one answer to "who is this person", not two overlapping ones.
• Kept apart where they should be apart. Concepts that are genuinely separate (for example authorisation vs. authentication, or SLA vs. routing) are kept in their own domains to avoid confusing development or day-to-day use.

We would be glad to converge these changes with the project together — finding the right baseline with you, and keeping as much of the work intact as is sensible for the project.

The contribution, as a reviewable stack

The work is large, so we have split it into 10 pull requests by concern, ordered by dependency and intended to be reviewed and merged in that order. Merging them in order reproduces our integrated branch exactly (verified: the cumulative tip of the series is byte-identical to it).

#	PR	Branch	Scope
1	#273	01-data-model-foundation	Data model, branded TypeIDs and migrations (foundation)
2	#274	02-rbac-authz-teams	RBAC: roles, permissions, teams, organisations, auth surfaces
3	#275	03-events-audit-webhooks	Event dispatch, audit log, webhooks, notifications
4	#276	04-ticketing-crm-core	Ticketing / CRM core (tickets, contacts, statuses, Customers)
5	#277	05-sla-inboxes-routing	SLA policies, inboxes, business hours, routing rules
6	#278	06-github-sync-and-ticket-email	GitHub ticket sync, ticket email, integration platform
7	#279	07-widget-profiles	Scoped widget profiles and ticket submission
8	#280	08-api-openapi-mcp	OpenAPI surface, MCP tools, conversation actions, API keys
9	#281	09-content-visibility	Changelog/help-centre visibility, segments, portal tabs
10	#282	10-test-coverage	Broad test suite and supporting infrastructure

Each PR follows the project's conventions — a conventional-commit title and a What / Concepts / How it works / How to use / Safety / Verification body — so it can be read and reviewed on its own.

Guidelines for merging the stack

1. Review and merge in numerical order (PR 1 → PR 10). The footer of every PR carries the same ordered list.
2. Each PR is opened against main. Until the PRs before it have merged, a PR's diff is cumulative — it also contains the earlier batches. As the earlier PRs merge and we rebase the next branch onto main, each diff reduces to just its own batch. We will keep the series rebased and current as it lands, so the queue stays clean for you.
3. Per-PR checklist (each PR documents its own): bun run typecheck, bun run lint, and the unit/integration tests included with that batch.

Our commitment

The reason we are upstreaming this is to converge. We would much rather these features live inside the project, maintained as part of it, than carry a divergent fork — that outcome aligns our interests with yours, and it is the outcome we are working towards.

To make that an easy decision for the project to live with:

• We have done the work up front so the surface is cheap to own: additive changes that reuse existing patterns, broad test coverage, per-PR documentation, and conventions matched to the codebase — so the new code arrives with the tests and docs that keep it maintainable.
• We will stay closely engaged through the merge — prompt responses in review, splitting or reshaping PRs, and dropping anything that does not fit — so the integration effort lands on us, not on you.
• From running this in production we will continue to send fixes and improvements back, and share the real-world usage patterns and benefits we see, so the project keeps gaining from the deployment and not only from the diff.

Contact

We would welcome a conversation about the best way to take this forward.

• Melih Sünbül — m.sunbul@excellence-cloud.com
• LinkedIn: https://www.linkedin.com/in/melih-sunbul/

Thank you for the project and for the care you put into it. We have tried to match that standard in how this contribution is prepared, and we are entirely flexible on how we proceed.

[DereckRadford]

This is awesome of you @melihsunbul excited to see this work added to the repo.

[mortondev]

Hey @melihsunbul,

This is a brilliant thing to see, thank you. There's clearly been a lot of work put into this, and just as much care in how you've prepared it for review. Splitting it into a dependency-ordered, individually reviewable stack with matching conventions and per-PR docs makes a real difference, and it's genuinely appreciated.

There's a lot of surface area to get through, so I'll need a little time to work through everything properly across the PRs before I can give you proper feedback. I'd rather do that thoughtfully and do it justice than rush a reaction to something this substantial.

The good news is the direction really resonates. Expanding Quackback into areas like customer support is something I'm keen on anyway, so a lot of this lands on ground I'm already excited about. I should be upfront that I've yet to review all of the functionality in any detail, so it's a bit early for me to say exactly how much makes it in as-is, some of that will come down to working through the PRs and finding the right baseline together as you've suggested. But I'm going into it hopeful and wanting to keep as much intact as makes sense for the project.

I'll follow up properly once I've had a chance to get through the stack. Thanks again for choosing to bring this back and build with the project rather than around it, that means a lot.

[melihsunbul]

Hey @melihsunbul,

This is a brilliant thing to see, thank you. There's clearly been a lot of work put into this, and just as much care in how you've prepared it for review. Splitting it into a dependency-ordered, individually reviewable stack with matching conventions and per-PR docs makes a real difference, and it's genuinely appreciated.

There's a lot of surface area to get through, so I'll need a little time to work through everything properly across the PRs before I can give you proper feedback. I'd rather do that thoughtfully and do it justice than rush a reaction to something this substantial.

The good news is the direction really resonates. Expanding Quackback into areas like customer support is something I'm keen on anyway, so a lot of this lands on ground I'm already excited about. I should be upfront that I've yet to review all of the functionality in any detail, so it's a bit early for me to say exactly how much makes it in as-is, some of that will come down to working through the PRs and finding the right baseline together as you've suggested. But I'm going into it hopeful and wanting to keep as much intact as makes sense for the project.

I'll follow up properly once I've had a chance to get through the stack. Thanks again for choosing to bring this back and build with the project rather than around it, that means a lot.

Hi @mortondev ,

Thank you again for your time and for maintaining Quackback.

We are approaching the point where we will begin using this version in production within our organisation. Our preference is still to move toward the official project image rather than rely on a long-term fork, and we would like to keep that transition as smooth as possible.

Given this timeline, it would be very helpful to maintain close communication during the review process and to have visibility into the expected direction, priorities, and any key concerns early on. This would help us plan our rollout responsibly while keeping the implementation aligned with the project’s standards.

We understand that some adjustments may be needed as part of the review, and we are open to incorporating reasonable changes where necessary. A clear review path and ongoing feedback would make it much easier for us to converge on an upstream-compatible solution.

Thank you once more for the project and for considering the contribution. We appreciate your guidance and look forward to working through the review process smoothly.

[melihsunbul]

Hi @mortondev,

I have updated my PR branches not to conflict with your latest Unified Authentication work, FYI.