mirror of
https://github.com/hanzoai/team.git
synced 2026-09-30 01:57:35 +00:00
* docs(sidebar): group Integrations Guide and Administration Guide > Configure Both sections were flat lists (20 and 34 items respectively) with no logical grouping, unlike Overview/Deployment Guide which already got manual groupings. Adds the same override pattern: - Integrations Guide: group by integration type (Chat & Meeting Interop, ITSM & Dev Tools, No-Code Automation, Built-in Integrations with Webhooks/Slash Commands sub-groups). - Administration Guide > Configure: group the ~12 settings-reference pages under one category, plus Search, Calls, Storage & Database, Email & Notifications, Billing & Account, and Branding groups. AI Agents Configuration stays a standalone top-level entry (3rd, after System Console Settings and Search) rather than being buried in a misc/optional bucket. * docs(sidebar): document the manual grouping override pattern in README Nothing explained how OVERVIEW_GROUPS/DEPLOYMENT_GROUPS (and now ADMIN_CONFIGURE_GROUPS/INTEGRATIONS_GROUPS) work, or what to do when adding a new file to one of these sections. The script already warns on orphaned files, but that warning is easy to miss if you don't know the override mechanism exists in the first place. * docs(sidebar): reorganize gen-documentation-sidebar.mjs, config on top Pure reorganization, no behavior change (verified byte-identical sidebar JSON output before/after). All manual-grouping config (*_GROUPS/*_ROOT_ORDER/*_HIDDEN constants for Overview, Deployment Guide, Administration Guide > Configure, Integrations Guide) now lives together at the top of the file, and all functions (generic helpers, per-section builders, main) live together at the bottom. Previously each section's config and builder functions were interleaved in file order, so adding a page to one section meant scanning past unrelated sections' logic to find where its config lived. * docs(sidebar): remove the empty Samples section Sphinx never had a "Samples" navigation section — source/samples/ in the Sphinx repo is marked :orphan: and deliberately excluded from any toctree; it's a folder of downloadable static assets (JSON/XML/YAML/ CSV/zip) referenced inline via :download: from ~5 unrelated pages (logging, EMM mobile deploy, Grafana/Loki centralized logging, compliance export), never a browsable page. The migrated docs/main/samples/index.mdx was an empty stub (frontmatter only, no content), so it rendered as an empty top-level sidebar category with nothing underneath — the "looks broken, not coming soon" problem. Removed the stub page and the corresponding TOP_LEVEL entry in the sidebar generator. Note: the actual downloadable sample files were never migrated into the new site's static assets — the 4 migrated pages that reference them still link to github.com/mattermost/docs (the old repo) instead of being self-hosted. Tracked as a separate follow-up, not fixed here. * docs: self-host downloadable sample files instead of linking the old repo Four migrated pages (logging, EMM mobile deploy, Grafana/Loki centralized logging, compliance export) linked their downloadable sample files (JSON/XML/YAML/zip) to github.com/mattermost/docs — the old Sphinx repo — instead of hosting them on the new site. Every other static asset (images) was copied into docs/site/static/ during migration; these were missed. Copies the 8 referenced files into docs/site/static/files/samples/ and repoints all 8 links to the self-hosted /files/samples/... paths, matching the existing /images/... convention used everywhere else in this content tree. * docs(sidebar): remove the Recipes top-level nav section The Sphinx source for this content (recipes/product-vulnerability- incident.rst) is marked :orphan: with an explicit comment: "This page is intentionally not accessible via the LHS" — Sphinx never surfaced it as a navigable section either. The migrated page (docs/main/recipes/product-vulnerability-incident.mdx) was auto-promoted into a full top-level sidebar category by the filesystem-driven generator, at equal visual weight to sections with 10+ items despite having exactly 1. Removing the TOP_LEVEL entry matches Sphinx's original intent — the page stays reachable by direct URL, just not discoverable via the sidebar. * docs(sidebar): regroup Administration Guide > Manage by task Manage had 37 files split into a flat top level (19) plus a nested manage/admin/ sub-folder (18) — a raw filesystem artifact, not a real Sphinx grouping: Sphinx has no manage-index.rst/toctree that groups this content, and the admin/ sub-folder is never surfaced as its own nav level in Sphinx's actual sidebar. Worse, the flat-vs-admin split was internally inconsistent — related pages (monitoring/health, billing, user/access management) were each scattered across both buckets rather than following any coherent theme. Replaces both with task-based groups: User & Access Management (including an Attribute-Based Access Control sub-group), Server Configuration & Maintenance, Monitoring & Diagnostics, Billing & Licensing, Cloud Workspace Management, Notifications & Surveys, Content & Product Governance, and Data Export & Migration. Customize Branding stays a standalone entry (single item, not worth its own group). * docs(sidebar): harden buildAdminGuideSidebar's category resolution Filter the items-fallback lookup to type === 'doc' before reading .id, matching the same pattern already used in buildDeploymentSidebar (dirNameFromId), instead of relying on category items implicitly lacking an .id field. Also track whether the Configure and Manage sub-categories were actually found and regrouped, and warn if either is missing — so a future filesystem change under Administration Guide (renamed/removed sub-folder) surfaces as a build warning instead of silently leaving the manual grouping override unapplied. --------- Co-authored-by: Hanzo Dev <[email protected]>