Skip to content

feat(portal): changelog taxonomy/visibility, help-center audience, segments & portal tabs#281

Open
melihsunbul wants to merge 10 commits into
QuackbackIO:mainfrom
ExcellenceCloudGmbH:09-content-visibility
Open

feat(portal): changelog taxonomy/visibility, help-center audience, segments & portal tabs#281
melihsunbul wants to merge 10 commits into
QuackbackIO:mainfrom
ExcellenceCloudGmbH:09-content-visibility

Conversation

@melihsunbul

@melihsunbul melihsunbul commented Jun 22, 2026

Copy link
Copy Markdown

What

Audience and visibility controls for content surfaces: changelog taxonomy and segment visibility, help-centre category audience, segments, user attributes, and portal tab customisation.

Concepts

  • Segment — a defined audience (by user attributes, linked contact or organisation attributes) that visibility rules target.
  • Audience (public / targeted) — a help-centre category or changelog entry is either visible to everyone or restricted to named segments/principals via allowedSegmentIds/allowedPrincipalIds.
  • Visibility config — an organisation-level default for changelog visibility, stored in settings.
  • Portal tab config / segment override — which portal tabs are visible, set per organisation and optionally overridden per segment. Tabs are opt-out: visible unless configured otherwise, so existing portals are unchanged.

How it works

  • Changelog (domains/changelog/) — taxonomy/metadata, changelogSegmentVisibility plus a changelogVisibilityConfig settings column, changelog-visibility.service.ts; public changelog filtered by segment; admin /admin/settings/changelog-visibility and a public changelog-filters component.
  • Help centre (domains/help-center/) — category audience via allowedSegmentIds/allowedPrincipalIds, help-center.visibility.ts; portal articles/categories filtered by viewer segment; audience fields on the category form.
  • Segments and user attributes (domains/segments/, domains/user-attributes/) — segments extended with linked-contact/organisation attributes; /api/v1/segments, /user-attributes.
  • Portal tabs (domains/portal/) — portal_tab_config settings column plus portal_tab_segment_overrides; getPortalTabConfigFn/updatePortalTabConfigFn/updateSegmentTabOverridesFn (admin-only, audit-logged); /api/v1/internal/portal-tabs; admin /admin/settings/portal-tabs; buildNavItems() is opt-out.
  • Tier flagportalTabCustomization (OSS: always on).

How to use

  • Restrict a help-centre category: edit the category, set audience to targeted, and choose the segments/principals who may see it.
  • Scope the changelog: Settings → Changelog visibility (/admin/settings/changelog-visibility) — set org-level defaults and per-segment restrictions; the public changelog and its filters respect them.
  • Define segments: manage segments (and the user attributes they match) from the Customers/segments area.
  • Customise portal tabs: Settings → Portal tabs (/admin/settings/portal-tabs) — hide tabs for the workspace, and add per-segment overrides for signed-in users.

Safety

  • Visibility defaults are permissive/opt-out, so existing portals are unchanged until an operator configures restrictions.
  • Tab and visibility writes are admin-only and audit-logged.

Verification

  • bun run typecheck, bun run lint; help-centre-visibility, categories API, changelog visibility service and segments tests (included).

Depends on 08-api-openapi-mcp.


📚 This is a stacked series — please review & merge in order

These 10 PRs are split by concern and ordered by dependency. Each is opened against main, so 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. Merging all 10 in order reproduces our integrated branch exactly (verified: the cumulative tip of the series is byte-identical to it).

Order (by branch):

  1. 01-data-model-foundation — data model, TypeIDs, migrations
  2. 02-rbac-authz-teams — RBAC, teams, organisation & auth surfaces
  3. 03-events-audit-webhooks — event dispatch, audit log, webhooks, notifications
  4. 04-ticketing-crm-core — ticketing / CRM core
  5. 05-sla-inboxes-routing — SLA policies, inboxes, business hours, routing
  6. 06-github-sync-and-ticket-email — GitHub ticket sync, ticket email, integration platform
  7. 07-widget-profiles — scoped widget profiles + ticket submission
  8. 08-api-openapi-mcp — OpenAPI surface, MCP tools, conversation actions, API keys
  9. 09-content-visibility — changelog/help-centre visibility, segments, portal tabs
  10. 10-test-coverage — broad unit/integration test suite + supporting infra

Part of the roadmap: #283

@CLAassistant

CLAassistant commented Jun 22, 2026

Copy link
Copy Markdown

CLA assistant check
All committers have signed the CLA.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants