diff --git a/.changeset/business-hours-spillover-setup-faq-glossary.md b/.changeset/business-hours-spillover-setup-faq-glossary.md new file mode 100644 index 000000000..b2b86dc78 --- /dev/null +++ b/.changeset/business-hours-spillover-setup-faq-glossary.md @@ -0,0 +1,53 @@ +--- +'hotcrm': patch +--- + +Write the three remaining business-hours claims to what the app actually ships, +in all three locales. PR #924 fixed the two on `service/sla-and-escalation`; the +same promise was still being made on the setup checklist, in the FAQ and in the +glossary, and the setup page had ended up contradicting the SLA page outright. +Every claim was re-confirmed against `origin/main` first: `business_hours`, +`workingHours`, `businessCalendar` and `slaCalendar` have zero occurrences in +`src/`, the only `business.?hour` matches are three product-description strings +in the seed data, and the only code that computes an SLA deadline is +`due.setHours(due.getHours() + 4)` in `src/objects/case.hook.ts` — wall-clock +hours, stamped for `critical` and no other priority. + +**`administration/setup` no longer sends admins to a screen that does not +exist.** Day-1 section 2 was a checklist — three checkboxes under a bold +**Setup → Business Hours** heading — telling a new admin to enter working days, +working hours and the year's holidays, then closing with "business hours drive +SLA calculations". There is no such screen, none of the three settings exist, +and after #924 the page it linked to says so in as many words, so the two pages +disagreed about the same feature. The section keeps its number and its name (a +reader who was sent looking for it needs to find out what happened to it) and +now states plainly that there is nothing to configure, that deadlines therefore +run on calendar hours, and that the four-hour Critical target is the only +deadline the app computes. The old example, "resolve within 8 business hours", +is High's service commitment: nothing stamps `sla_due_date` for High, so it is +now named as a promise the team keeps rather than a clock the app runs. + +**`reference/faq` no longer lists two fictional preconditions for the SLA +clock.** "My SLA clock isn't running" told the reader to check that business +hours were configured and that the case's priority had an SLA defined, then +added that cases without a priority get the default SLA. None of the three is +real — there is no business-hours setup, no per-priority SLA definition screen +and no default SLA. This was the expensive one: an admin whose High case was not +being timed went looking for a configuration problem, when the reason is that +the hook stamps `sla_due_date` for `critical` only. The answer now opens by +saying there is no countdown at all, and the checklist is the real one — open +status (`case_sla_monitor` filters `status: { $nin: ['resolved', 'closed'] }`), +a due date present at all, and that due date already past with an hourly sweep +having run since. The first bullet, open status, was already correct and is +unchanged. + +**`reference/glossary` keeps the term and loses the false half.** The entry +defined business hours as "working days and hours used in SLA calculations", +which describes a concept this app does not have and asserts a use it does not +make. It now gives the industry meaning, states that HotCRM has none of it, and +points at where the one real deadline comes from. + +Whether the app *should* grow a business-hours calendar, per-priority SLA +definitions or a default SLA stays open in #595 — this change records today's +behaviour only. Documentation in three locales; no metadata under `src/` +changed. Refs #928, #917, #924, #903. diff --git a/content/docs/administration/setup.mdx b/content/docs/administration/setup.mdx index 2b0bd4f2a..42f6d13dd 100644 --- a/content/docs/administration/setup.mdx +++ b/content/docs/administration/setup.mdx @@ -17,15 +17,11 @@ Navigate to **Setup → Company Information**: - [ ] Fiscal year start month (used by all forecast reports) - [ ] Default language -### 2. Business hours +### 2. Business hours — nothing to configure -**Setup → Business Hours**: +**There is no Setup → Business Hours screen.** This app ships no working-day calendar, no working-hours window and no holiday list — nothing to fill in here, and nothing a deadline could be counted against. The section is kept only so the admin who came looking for that screen stops looking. -- [ ] Working days (e.g., Mon–Fri) -- [ ] Working hours (e.g., 9 AM – 6 PM) -- [ ] Holidays for the year - -Business hours drive [SLA calculations](/docs/service/sla-and-escalation) — e.g., "resolve within 8 business hours" uses these. +What follows from that is on the SLA side: deadlines run on **calendar hours**. The one deadline this app computes is the Critical case target — `src/objects/case.hook.ts` adds four hours to the wall clock (`due.setHours(due.getHours() + 4)`) — so a Critical case opened at 4pm on a Friday is due at 8pm that same Friday, and nights, weekends and holidays all count against it. No other priority is stamped with a due date at all: the 8-hour High target and the rest are service promises your team keeps, not clocks the app runs. See [SLA & Escalation](/docs/service/sla-and-escalation). ### 3. Email setup diff --git a/content/docs/administration/setup.zh-Hans.mdx b/content/docs/administration/setup.zh-Hans.mdx index 0f2f1c74a..5e4d5378b 100644 --- a/content/docs/administration/setup.zh-Hans.mdx +++ b/content/docs/administration/setup.zh-Hans.mdx @@ -17,15 +17,11 @@ description: 让 HotCRM 为你的团队做好生产准备的第一周任务。 - [ ] 财年起始月份（所有预测报表都会用到） - [ ] 默认语言 -### 2. 工作时间 +### 2. 营业时间 —— 没有需要配置的东西 -**设置 → 工作时间**： +**不存在“设置 → 营业时间”这个屏幕。** 本应用没有工作日日历，没有工作时段设置，也没有节假日清单 —— 这里没有任何可填的项，也不存在任何可供截止时间去对照的东西。这一节保留下来，只是为了让被指去找那个屏幕的管理员别再找了。 -- [ ] 工作日（例如周一至周五） -- [ ] 工作时段（例如上午 9 点 – 下午 6 点） -- [ ] 当年的假期 - -工作时间驱动 [SLA 计算](/zh-Hans/docs/service/sla-and-escalation) —— 例如“在 8 个工作小时内解决”就用到了这些。 +由此带来的后果落在 SLA 一侧：截止时间按**日历小时**走。本应用唯一会算出来的截止时间是 Critical 工单的目标 —— `src/objects/case.hook.ts` 往当前时钟上加 4 小时（`due.setHours(due.getHours() + 4)`）—— 所以一个周五下午 4 点建的 Critical 工单，截止时间就是同一个周五晚上 8 点，夜间、周末与节假日一律照算进去。其余优先级根本不会被打上截止时间：High 的 8 小时目标以及其余各档，都是你的团队自己守的服务承诺，不是应用在跑的计时器。参见 [SLA 与升级](/zh-Hans/docs/service/sla-and-escalation)。 ### 3. 电子邮件设置 diff --git a/content/docs/administration/setup.zh-Hant.mdx b/content/docs/administration/setup.zh-Hant.mdx index c7664c8d6..6b05c1c66 100644 --- a/content/docs/administration/setup.zh-Hant.mdx +++ b/content/docs/administration/setup.zh-Hant.mdx @@ -17,15 +17,11 @@ description: 讓 HotCRM 為你的團隊做好生產準備的第一週任務。 - [ ] 財年起始月份（所有預測報表都會用到） - [ ] 預設語言 -### 2. 工作時間 +### 2. 營業時間 —— 沒有需要設定的東西 -**設定 → 工作時間**： +**不存在「設定 → 營業時間」這個畫面。** 本應用沒有工作日日曆，沒有工作時段設定，也沒有假日清單 —— 這裡沒有任何可填的項目，也不存在任何可供截止時間去對照的東西。這一節保留下來，只是為了讓被指去找那個畫面的管理員別再找了。 -- [ ] 工作日（例如週一至週五） -- [ ] 工作時段（例如上午 9 點 – 下午 6 點） -- [ ] 當年的假期 - -工作時間驅動 [SLA 計算](/zh-Hant/docs/service/sla-and-escalation) —— 例如「在 8 個工作小時內解決」就用到了這些。 +由此帶來的後果落在 SLA 一側：截止時間按**日曆小時**走。本應用唯一會算出來的截止時間是 Critical 工單的目標 —— `src/objects/case.hook.ts` 往當前時鐘上加 4 小時（`due.setHours(due.getHours() + 4)`）—— 所以一個週五下午 4 點建的 Critical 工單，截止時間就是同一個週五晚上 8 點，夜間、週末與假日一律照算進去。其餘優先順序根本不會被打上截止時間：High 的 8 小時目標以及其餘各檔，都是你的團隊自己守的服務承諾，不是應用在跑的計時器。參見 [SLA 與升級](/zh-Hant/docs/service/sla-and-escalation)。 ### 3. 電子郵件設定 diff --git a/content/docs/reference/faq.mdx b/content/docs/reference/faq.mdx index ad3950e20..3e43a2640 100644 --- a/content/docs/reference/faq.mdx +++ b/content/docs/reference/faq.mdx @@ -86,13 +86,13 @@ The **Process Monitor** (Setup → Process Monitor) shows the last 24 hours of a ### My SLA clock isn't running. -Check: +Nothing counts down in this app — there is no live SLA timer to watch. What exists is a due date stamped on Critical cases and an hourly sweep that reports a breach after the fact. Check: -- The case is in an **open status** (not Resolved / Closed). -- **Business hours** are configured. -- The case's **priority** has an SLA defined. +- The case is in an **open status** (not Resolved / Closed) — the hourly `case_sla_monitor` sweep filters `status: { $nin: ['resolved', 'closed'] }`, so a resolved case is never picked up. +- The case has an **SLA Due Date** at all. Only **Critical** gets one automatically: `src/objects/case.hook.ts` stamps `sla_due_date` four hours out, and no other priority is stamped. A case with a blank due date is never a candidate for the sweep, so **SLA Violated** stays `false` however long it stays open. (Typing a due date in by hand works — the sweep then treats that case like any other.) +- That due date is already **in the past**, and a sweep has run since. The sweep is hourly and only flags cases that are already over, so a case resolved late but before the next sweep is never flagged at all. -Cases without a priority get the *default* SLA; if none is set, no clock runs. +**There is no business-hours setting to check** — no working-day calendar, no holiday list, no *Setup → Business Hours* screen anywhere in this app. Those four hours are wall-clock hours, and nights, weekends and holidays count against them. **There is also no per-priority SLA definition and no default SLA**: the four-hour Critical target is the only one the app keeps, written into the hook rather than configured, and High / Medium / Low are service promises your team keeps by hand. See [SLA & Escalation](/docs/service/sla-and-escalation). ### Auto-numbering jumped (e.g., from #1234 to #1267). diff --git a/content/docs/reference/faq.zh-Hans.mdx b/content/docs/reference/faq.zh-Hans.mdx index 871c33422..9413d27db 100644 --- a/content/docs/reference/faq.zh-Hans.mdx +++ b/content/docs/reference/faq.zh-Hans.mdx @@ -86,13 +86,13 @@ Copilot 遵守你的共享设置 —— 如果你看不到它，它也看不到 ### 我的 SLA 计时器没有运行。 -检查： +本应用里没有任何东西在倒计时 —— 不存在可以盯着看的实时 SLA 计时器。真实存在的是：给 Critical 工单打上的一个截止时间，加上一个每小时跑一次、事后标记违约的扫描。检查： -- 案例处于**打开状态**（不是 Resolved / Closed）。 -- 已配置**营业时间**。 -- 案例的**优先级**已定义 SLA。 +- 工单处于**打开状态**（不是 Resolved / Closed）—— 每小时的 `case_sla_monitor` 扫描按 `status: { $nin: ['resolved', 'closed'] }` 过滤，所以已解决的工单永远不会被捞进来。 +- 工单**根本有没有 SLA 截止时间**。只有 **Critical** 会被自动打上：`src/objects/case.hook.ts` 把 `sla_due_date` 打在 4 小时之后，其余优先级一概不打。截止时间为空的工单永远进不了扫描的候选集，所以无论它开着多久，**SLA Violated** 都保持 `false`。（手工填一个截止时间是有效的 —— 之后扫描会像对待其他工单一样对待它。） +- 那个截止时间**已经过去**，并且此后已经跑过一次扫描。扫描每小时一次，且只标记已经超期的工单，所以一个超期但在下一次扫描之前就被解决的工单，根本不会被标记。 -没有优先级的案例会获得*默认* SLA；如果未设置，则不运行计时器。 +**没有营业时间设置可查** —— 本应用里没有工作日日历，没有节假日清单，也不存在“设置 → 营业时间”这个屏幕。那 4 小时是挂钟小时，夜间、周末与节假日一律照算。**同样不存在“按优先级定义 SLA”这件事，也没有默认 SLA**：Critical 的 4 小时是本应用唯一守的目标，它写死在钩子里而不是配出来的；High / Medium / Low 是你的团队自己守的服务承诺。参见 [SLA 与升级](/zh-Hans/docs/service/sla-and-escalation)。 ### 自动编号跳号了（例如，从 #1234 跳到 #1267）。 diff --git a/content/docs/reference/faq.zh-Hant.mdx b/content/docs/reference/faq.zh-Hant.mdx index a72bc24a0..cd4602f37 100644 --- a/content/docs/reference/faq.zh-Hant.mdx +++ b/content/docs/reference/faq.zh-Hant.mdx @@ -86,13 +86,13 @@ Copilot 遵守你的共享設定 —— 如果你看不到它，它也看不到 ### 我的 SLA 計時器沒有執行。 -檢查： +本應用裡沒有任何東西在倒數 —— 不存在可以盯著看的即時 SLA 計時器。真實存在的是：給 Critical 工單打上的一個截止時間，加上一個每小時跑一次、事後標記違約的掃描。檢查： -- 案例處於**開啟狀態**（不是 Resolved / Closed）。 -- 已設定**營業時間**。 -- 案例的**優先順序**已定義 SLA。 +- 工單處於**開啟狀態**（不是 Resolved / Closed）—— 每小時的 `case_sla_monitor` 掃描按 `status: { $nin: ['resolved', 'closed'] }` 過濾，所以已解決的工單永遠不會被撈進來。 +- 工單**到底有沒有 SLA 截止時間**。只有 **Critical** 會被自動打上：`src/objects/case.hook.ts` 把 `sla_due_date` 打在 4 小時之後，其餘優先順序一概不打。截止時間為空的工單永遠進不了掃描的候選集，所以無論它開著多久，**SLA Violated** 都保持 `false`。（手工填一個截止時間是有效的 —— 之後掃描會像對待其他工單一樣對待它。） +- 那個截止時間**已經過去**，並且此後已經跑過一次掃描。掃描每小時一次，且只標記已經逾期的工單，所以一個逾期但在下一次掃描之前就被解決的工單，根本不會被標記。 -沒有優先順序的案例會獲得*預設* SLA；如果未設定，則不執行計時器。 +**沒有營業時間設定可查** —— 本應用裡沒有工作日日曆，沒有假日清單，也不存在「設定 → 營業時間」這個畫面。那 4 小時是掛鐘小時，夜間、週末與假日一律照算。**同樣不存在「按優先順序定義 SLA」這件事，也沒有預設 SLA**：Critical 的 4 小時是本應用唯一守的目標，它寫死在鉤子裡而不是設定出來的；High / Medium / Low 是你的團隊自己守的服務承諾。參見 [SLA 與升級](/zh-Hant/docs/service/sla-and-escalation)。 ### 自動編號跳號了（例如，從 #1234 跳到 #1267）。 diff --git a/content/docs/reference/glossary.mdx b/content/docs/reference/glossary.mdx index 3b5d26abe..ecb9d66e5 100644 --- a/content/docs/reference/glossary.mdx +++ b/content/docs/reference/glossary.mdx @@ -31,7 +31,7 @@ description: CRM and platform terms — alphabetised so you can stop bluffing in **Bookings** — Closed-won contract value in a period. Includes new + expansion + renewal. -**Business hours** — Working days and hours used in SLA calculations. +**Business hours** — The working days and hours a deadline is counted against, in CRMs that have them. **HotCRM does not have them**: no working-day calendar, no holiday list, no *Setup → Business Hours* screen, nothing in its metadata a deadline could be measured against. Its one computed deadline — the four hours on a Critical case — is added to the wall clock, so nights, weekends and holidays all count. See [SLA & Escalation](/docs/service/sla-and-escalation). ## C diff --git a/content/docs/reference/glossary.zh-Hans.mdx b/content/docs/reference/glossary.zh-Hans.mdx index 08d31fa31..ebdf959bd 100644 --- a/content/docs/reference/glossary.zh-Hans.mdx +++ b/content/docs/reference/glossary.zh-Hans.mdx @@ -31,7 +31,7 @@ description: CRM 与平台术语 —— 按字母排序，让你在会议中不 **Bookings（签约额）** —— 某一期间内的赢单合同价值。包括新增 + 扩展 + 续约。 -**Business hours（营业时间）** —— SLA 计算中使用的工作日和工作时间。 +**Business hours（营业时间）** —— 在提供这项设置的 CRM 里，指截止时间所对照的工作日与工作时段。**HotCRM 没有这个概念**：没有工作日日历，没有节假日清单，没有“设置 → 营业时间”这个屏幕，元数据里也不存在任何可供截止时间去对照的东西。它唯一算得出来的截止时间 —— Critical 工单的那 4 小时 —— 是加在挂钟上的，夜间、周末与节假日一律照算。参见 [SLA 与升级](/zh-Hans/docs/service/sla-and-escalation)。 ## C diff --git a/content/docs/reference/glossary.zh-Hant.mdx b/content/docs/reference/glossary.zh-Hant.mdx index 421c127a8..31a342691 100644 --- a/content/docs/reference/glossary.zh-Hant.mdx +++ b/content/docs/reference/glossary.zh-Hant.mdx @@ -31,7 +31,7 @@ description: CRM 與平台術語 —— 按字母排序，讓你在會議中不 **Bookings（簽約額）** —— 某一期間內的贏單合約價值。包括新增 + 擴展 + 續約。 -**Business hours（營業時間）** —— SLA 計算中使用的工作日和工作時間。 +**Business hours（營業時間）** —— 在提供這項設定的 CRM 裡，指截止時間所對照的工作日與工作時段。**HotCRM 沒有這個概念**：沒有工作日日曆，沒有假日清單，沒有「設定 → 營業時間」這個畫面，中繼資料裡也不存在任何可供截止時間去對照的東西。它唯一算得出來的截止時間 —— Critical 工單的那 4 小時 —— 是加在掛鐘上的，夜間、週末與假日一律照算。參見 [SLA 與升級](/zh-Hant/docs/service/sla-and-escalation)。 ## C