feat(nav): each persona's own work first in navigation and default views (#2367)

.changeset/2367-own-work-first-navigation.md

@@ -0,0 +1,18 @@
+---
+"hotcrm": minor
+---
+
+Clause-②: no
+Metadata-protocol: none
+
+**Each persona's own work comes first in the sidebar and in the default views (#2367).** Who may read what is unchanged, and every persona opens the app where it did before.
+
+- **Sales reps:** the sidebar runs **Sales Home**, then **Sales**. The **Service** group, which held only **Knowledge** for a rep, is no longer shown to a rep; a rep's **Knowledge** is the last entry of **Sales** and opens the published articles, so the search box still finds articles by title.
+- **Service agents and service managers:** **Opportunities** and **My Deals** are no longer in their sidebar. Both lists were always empty for them; the deals stay readable from an account's related list.
+- **Accounts:** the tabs open with **My Accounts**, **At-Risk Accounts** and **Enterprise Accounts**, ahead of the card and map views, so a rep's own list is no longer in the overflow menu.
+- **Opportunities:** **My Open Deals** follows **Open Deals**, ahead of the board, calendar, timeline and card views.
+- **SLA Calendar:** shows open cases only; resolved and closed cases are left out.
+- **Campaign Schedule** opens at Month zoom and **Contract Terms** at Quarter zoom, instead of Day.
+- **All Forecasts:** one heading per period, newest first, instead of two nested headings over each row.
+
+The documentation site's quick tour, Sales, Cases, SLA and Forecasting pages and the in-app Getting Started page say what each surface does now, in English and Chinese.

content/docs/getting-started/quick-tour.mdx

@@ -51,7 +51,7 @@ Inside HotCRM, the left nav opens with two pinned items — **Home**, which is t
 | Group | Contents |
 | --- | --- |
 | **Service** | Service Overview, Cases, Knowledge |
-| **Sales** | Leads, Accounts, Contacts, Opportunities, Sales Performance, Contracts, Quotes, Products, Price Books |
+| **Sales** | Leads, Accounts, Contacts, Opportunities, Sales Performance, Contracts, Quotes, Products, Price Books, Knowledge |
 | **My Work** | My Tasks, My Deals, My Leads, My Calendar, Inbox, My Cases |
 | **Activity** | Events, Sales Activity |
 | **Marketing** | Campaigns |
@@ -61,7 +61,7 @@ Inside HotCRM, the left nav opens with two pinned items — **Home**, which is t
 
 **Reports** and **Help** are collapsed when the app loads — **Service**, **Sales**, **My Work**, **Activity**, **Marketing** and **Insights** open themselves. Click **Reports** open before deciding a report isn't there. **Help** opens the in-app manuals; **Admin Manual** is shown to administrators only.
 
-The entries built on opportunities — **Home**, **Sales Home**, **Sales Performance**, **CRM Overview** and the four opportunity reports under **Reports** — are left out of the sidebar for anyone who cannot read opportunities, and for a service agent or service manager by position: they can still open their own deals from **Opportunities** and **My Deals**, but these dashboards and reports are not shown to them. Every other report asks the same of its own records: a service agent still gets the lead, account and case reports, and a user who cannot read cases does not get **Service Overview** or the three case reports. **Home** is left out for a sales rep as well, which is why a rep's sidebar starts at **Sales Home**. A sales rep works no cases, so a rep's sidebar also leaves out **Service Overview**, **Cases**, **My Cases** and the three case reports — **Cases by Status and Priority**, **SLA Performance** and **Cases Opened by Day**; **Knowledge** stays, because articles are read while selling too. **Service** is the first group because the app opens on the first entry a sidebar shows: for a service agent or service manager that is **Service Overview**.
+The entries built on opportunities — **Home**, **Sales Home**, **Sales Performance**, **CRM Overview** and the four opportunity reports under **Reports** — are left out of the sidebar for anyone who cannot read opportunities, and for a service agent or service manager by position: and as they own no deals, **Opportunities** and **My Deals**, which were always empty for them, are not shown to them either. Every other report asks the same of its own records: a service agent still gets the lead, account and case reports, and a user who cannot read cases does not get **Service Overview** or the three case reports. **Home** is left out for a sales rep as well, which is why a rep's sidebar starts at **Sales Home**. A sales rep works no cases, so a rep's sidebar also leaves out **Service Overview**, **Cases**, **My Cases** and the three case reports — **Cases by Status and Priority**, **SLA Performance** and **Cases Opened by Day**. A rep's **Knowledge** is the last entry of **Sales** instead, opening the published articles, so a rep's sidebar has no **Service** group at all. Everyone else finds **Knowledge** under **Service**. **Service** is the first group because the app opens on the first entry a sidebar shows: for a service agent or service manager that is **Service Overview**.
 
 One sidebar row per destination is deliberate. Where an object offers several ways of looking at the same records, those live as tabs across the top of that object's list page, not as extra rows in the nav — so the sidebar stays short enough to scan.
 

content/docs/getting-started/quick-tour.zh-Hans.mdx

@@ -53,7 +53,7 @@ description: HotCRM 的 5 分钟演练 —— 主页、你的第一条线索、
 | 分组 | 内容 |
 | --- | --- |
 | **Service** | Service Overview、Cases、Knowledge |
-| **Sales** | Leads、Accounts、Contacts、Opportunities、Sales Performance、Contracts、Quotes、Products、Price Books |
+| **Sales** | Leads、Accounts、Contacts、Opportunities、Sales Performance、Contracts、Quotes、Products、Price Books、Knowledge |
 | **My Work** | My Tasks、My Deals、My Leads、My Calendar、Inbox、My Cases |
 | **Activity** | Events、Sales Activity |
 | **Marketing** | Campaigns |
@@ -65,7 +65,7 @@ description: HotCRM 的 5 分钟演练 —— 主页、你的第一条线索、
 
 **Reports** 和 **Help** 这两个分组在应用加载时是折叠的——**Service**、**Sales**、**My Work**、**Activity**、**Marketing**、**Insights** 都会自动展开。先把 **Reports** 点开，再判断某份报表在不在这里。**Help** 打开应用内手册；**Admin Manual** 只对管理员显示。
 
-建立在商机之上的条目——**Home**、**Sales Home**、**Sales Performance**、**CRM Overview**，以及 **Reports** 下的四张商机报表——不能读取商机的人在侧边栏里看不到；服务坐席与服务经理也按岗位看不到它们：他们仍可从 **Opportunities** 与 **My Deals** 打开自己的商机，但这些仪表盘与报表不对他们显示。其余报表对各自的数据也是同样的要求：服务坐席照样看得到线索、客户与工单报表，而不能读取工单的人看不到 **Service Overview** 和那三张工单报表。销售代表也看不到 **Home**，所以销售代表的侧边栏从 **Sales Home** 开始。销售代表不处理工单，所以销售代表的侧边栏也看不到 **Service Overview**、**Cases**、**My Cases** 以及那三张工单报表——**Cases by Status and Priority**、**SLA Performance**、**Cases Opened by Day**；**Knowledge** 仍然保留，因为销售时也要查阅知识文章。**Service** 排在所有分组之首，是因为应用打开时落在侧边栏显示的第一个条目上：对服务坐席与服务经理来说，那就是 **Service Overview**。
+建立在商机之上的条目——**Home**、**Sales Home**、**Sales Performance**、**CRM Overview**，以及 **Reports** 下的四张商机报表——不能读取商机的人在侧边栏里看不到；服务坐席与服务经理也按岗位看不到它们：他们名下没有商机，**Opportunities** 与 **My Deals** 对他们总是空的，所以这两个条目也不对他们显示。其余报表对各自的数据也是同样的要求：服务坐席照样看得到线索、客户与工单报表，而不能读取工单的人看不到 **Service Overview** 和那三张工单报表。销售代表也看不到 **Home**，所以销售代表的侧边栏从 **Sales Home** 开始。销售代表不处理工单，所以销售代表的侧边栏也看不到 **Service Overview**、**Cases**、**My Cases** 以及那三张工单报表——**Cases by Status and Priority**、**SLA Performance**、**Cases Opened by Day**。销售代表的 **Knowledge** 改为 **Sales** 的最后一项，打开已发布的文章，所以销售代表的侧边栏里没有 **Service** 分组。其他人仍在 **Service** 下找到 **Knowledge**。**Service** 排在所有分组之首，是因为应用打开时落在侧边栏显示的第一个条目上：对服务坐席与服务经理来说，那就是 **Service Overview**。
 
 一个去处只占一行，这是刻意的。同一个对象如果有多种查看方式，它们是该对象列表页顶部的标签页，而不是导航里另起一行——这样侧边栏才短到能一眼扫完。
 

content/docs/getting-started/quick-tour.zh-Hant.mdx

@@ -53,7 +53,7 @@ description: HotCRM 的 5 分鐘演練 —— 主頁、你的第一條線索、
 | 分組 | 內容 |
 | --- | --- |
 | **Service** | Service Overview、Cases、Knowledge |
-| **Sales** | Leads、Accounts、Contacts、Opportunities、Sales Performance、Contracts、Quotes、Products、Price Books |
+| **Sales** | Leads、Accounts、Contacts、Opportunities、Sales Performance、Contracts、Quotes、Products、Price Books、Knowledge |
 | **My Work** | My Tasks、My Deals、My Leads、My Calendar、Inbox、My Cases |
 | **Activity** | Events、Sales Activity |
 | **Marketing** | Campaigns |
@@ -65,7 +65,7 @@ description: HotCRM 的 5 分鐘演練 —— 主頁、你的第一條線索、
 
 **Reports** 和 **Help** 這兩個群組在應用載入時是摺疊的——**Service**、**Sales**、**My Work**、**Activity**、**Marketing**、**Insights** 都會自動展開。先把 **Reports** 點開，再判斷某份報表在不在這裡。**Help** 開啟應用內手冊；**Admin Manual** 只對管理員顯示。
 
-建立在商機之上的條目——**Home**、**Sales Home**、**Sales Performance**、**CRM Overview**，以及 **Reports** 下的四張商機報表——不能讀取商機的人在側邊欄裡看不到；服務專員與服務經理也按職位看不到它們：他們仍可從 **Opportunities** 與 **My Deals** 打開自己的商機，但這些儀表板與報表不對他們顯示。其餘報表對各自的資料也是同樣的要求：服務專員照樣看得到線索、客戶與工單報表，而不能讀取工單的人看不到 **Service Overview** 和那三張工單報表。銷售代表也看不到 **Home**，所以銷售代表的側邊欄從 **Sales Home** 開始。銷售代表不處理工單，所以銷售代表的側邊欄也看不到 **Service Overview**、**Cases**、**My Cases** 以及那三張工單報表——**Cases by Status and Priority**、**SLA Performance**、**Cases Opened by Day**；**Knowledge** 仍然保留，因為銷售時也要查閱知識文章。**Service** 排在所有群組之首，是因為應用打開時落在側邊欄顯示的第一個條目上：對服務專員與服務經理來說，那就是 **Service Overview**。
+建立在商機之上的條目——**Home**、**Sales Home**、**Sales Performance**、**CRM Overview**，以及 **Reports** 下的四張商機報表——不能讀取商機的人在側邊欄裡看不到；服務專員與服務經理也按職位看不到它們：他們名下沒有商機，**Opportunities** 與 **My Deals** 對他們總是空的，所以這兩個條目也不對他們顯示。其餘報表對各自的資料也是同樣的要求：服務專員照樣看得到線索、客戶與工單報表，而不能讀取工單的人看不到 **Service Overview** 和那三張工單報表。銷售代表也看不到 **Home**，所以銷售代表的側邊欄從 **Sales Home** 開始。銷售代表不處理工單，所以銷售代表的側邊欄也看不到 **Service Overview**、**Cases**、**My Cases** 以及那三張工單報表——**Cases by Status and Priority**、**SLA Performance**、**Cases Opened by Day**。銷售代表的 **Knowledge** 改為 **Sales** 的最後一項，開啟已發布的文章，所以銷售代表的側邊欄裡沒有 **Service** 群組。其他人仍在 **Service** 下找到 **Knowledge**。**Service** 排在所有群組之首，是因為應用打開時落在側邊欄顯示的第一個條目上：對服務專員與服務經理來說，那就是 **Service Overview**。
 
 一個去處只佔一列，這是刻意的。同一個物件如果有多種檢視方式，它們是該物件列表頁頂部的標籤頁，而不是導覽裡另起一列——這樣側邊欄才短到能一眼掃完。
 

content/docs/sales/forecasting.mdx

@@ -47,7 +47,7 @@ The advice is therefore what it always was — when you write a snapshot by hand
 
 **A row stored before these rules shipped stays refused until its window is corrected.** The check reads the whole record on every save, not just the field you touched, so even an unrelated edit to such a row — a quota correction, a note — is rejected until the dates agree with the label. The correction itself is always accepted: put `period_start` and `period_end` back on the calendar period, and the row saves normally again.
 
-So you'll never see a record labelled “2026-07-01 through ???” — only the human label. A forecast's own title adds its owner after that label — **Q4 2026 · Nina Reyes** — so two reps' forecasts for the same quarter read apart on the record, in Recent items and in a lookup. A forecast with no owner is titled by its label alone. The name is taken from **Owner** when the forecast is saved: reassign it and the title follows; rename the user and the title changes at the forecast's next save. Dashboards group by `period_label` directly. The **All Forecasts** list groups on two levels, newest period first: by `period_start`, and under each start date by `period_label`, so every period gets a heading of its own (**Q4 2026**). It cannot group by the label alone, because a label sorts as text: *Sep 2026* would come before *Q4 2026*, and *Q4 2025* before *Oct 2026*. Nor can it group by the start date alone, because a quarter and the month that opens it start on the same day: **Q4 2026** and **Oct 2026** share one start-date heading and sit under it as two periods.
+So you'll never see a record labelled “2026-07-01 through ???” — only the human label. A forecast's own title adds its owner after that label — **Q4 2026 · Nina Reyes** — so two reps' forecasts for the same quarter read apart on the record, in Recent items and in a lookup. A forecast with no owner is titled by its label alone. The name is taken from **Owner** when the forecast is saved: reassign it and the title follows; rename the user and the title changes at the forecast's next save. Dashboards group by `period_label` directly. The **All Forecasts** list groups by `period_label`, one heading per period (**Q4 2026**), newest period first: the headings are ordered by each period's `period_start`, not by the label's text, which would put *Sep 2026* before *Q4 2026* and *Q4 2025* before *Oct 2026*. It groups by the label rather than by the start date because a quarter and the month that opens it start on the same day: **Q4 2026** and **Oct 2026** each get a heading of their own.
 
 ## How forecasts get created
 

content/docs/sales/forecasting.zh-Hans.mdx

@@ -47,7 +47,7 @@ description: 按负责人和周期的销售管道快照——营收预测的基
 
 **在这些规则上线之前就已经存错的行，会一直被拒收，直到它的窗口被改正。** 这项校验每次保存时读的是整条记录，而不只是你改动的那个字段，所以哪怕是一处无关的编辑——改个配额、加条备注——也会被拒绝，直到日期和标签对得上。改正本身则永远是被允许的：把 `period_start` 和 `period_end` 拨回到对应的日历周期，这一行就又能正常保存了。
 
-因此你绝不会看到一条标记为"2026-07-01 至 ???"的记录——只有人类可读的标签。预测记录本身的标题在这个标签后面加上负责人——**Q4 2026 · Nina Reyes**——所以两位销售同一季度的预测，在记录页、最近访问和查找框里都能区分开。没有负责人的预测，标题就只是标签本身。名字在保存预测时从**负责人**读取：把预测改派给别人，标题随之改变；用户改名后，标题要等这条预测下一次保存时才更新。仪表盘会直接按 `period_label` 分组。**全部预测**列表则分两层分组，最新的周期排在最前：先按 `period_start`，再在每个起始日之下按 `period_label`，所以每个周期都有自己的一行标题（**Q4 2026**）。它不能只按标签分组，因为标签是按文本排序的：*Sep 2026* 会排在 *Q4 2026* 前面，*Q4 2025* 会排在 *Oct 2026* 前面。它也不能只按起始日分组，因为一个季度和开启它的那个月是同一天开始的：**Q4 2026** 和 **Oct 2026** 共用同一个起始日标题，在它之下作为两个周期分开列出。
+因此你绝不会看到一条标记为"2026-07-01 至 ???"的记录——只有人类可读的标签。预测记录本身的标题在这个标签后面加上负责人——**Q4 2026 · Nina Reyes**——所以两位销售同一季度的预测，在记录页、最近访问和查找框里都能区分开。没有负责人的预测，标题就只是标签本身。名字在保存预测时从**负责人**读取：把预测改派给别人，标题随之改变；用户改名后，标题要等这条预测下一次保存时才更新。仪表盘会直接按 `period_label` 分组。**全部预测**列表按 `period_label` 分组，每个周期一个标题（**Q4 2026**），最新的周期排在最前：标题按各周期的 `period_start` 排序，而不是按标签的文本排序——按文本排，*Sep 2026* 会排在 *Q4 2026* 前面，*Q4 2025* 会排在 *Oct 2026* 前面。它按标签而不是按起始日分组，因为一个季度和开启它的那个月是同一天开始的：**Q4 2026** 和 **Oct 2026** 各有自己的标题。
 
 ## 预测是如何创建的