v24 第 13 批：旅程模块重构（双轨 → 一条记录 + 状态机）
用户原话：「旅程这个模块，我准备大改…如果按照计划行程和实际行程来分别管理，
会变的很复杂…根据我的想法，重构这个模块。」
—— 这不是加需求，是把「双轨」架构换成「一条记录 + 状态机」。
## 用户确认的三个决定
1. 两层：**活动**（顶层容器）→ **行程**（挂其下，字段沿用原节点）
2. **修正不立即转实际**：修正只是记录，行程仍标"计划（已修正 N 次）"，
要再点一次「标记为实际」才转实际
3. 老数据**按现有轨道自动迁移**（category=reality → stage=actual）
## 状态机（本次重构的心脏）
trip_nodes.stage：
· plan 计划行程 —— 唯一以「计划时间」上日程的状态，三个动作都能用
· actual 实际行程 —— 上日程（实际时间）+ 进「往年今日」
· skipped 未成行 —— **不上日程、不进往年今日**，但旅程里仍显示并标注
（用户："还是要显示，只不过要标记上"）
旧的 category(plan/reality) 保留作兼容，业务一律看 stage（saveNode 同步维护两者）。
## 三个动作（Trip.php）
· reviseNode —— 记一次修正。🔴 **第一次修正前先把原计划存成 seq=1 快照**，
否则用户要的"之前的计划行程数据要保留，为了以后做对比"就落空。**不动 stage**。
可无限次（seq 递增）。
· completeNode —— 实际＝计划，直接转 actual，**不产生修正历史**（没有变化就没有历史）。
· markActual —— 把（已修正过的）计划正式转 actual。
· skipNode —— **不是真删**，只置 stage='skipped'（用户明确"不要真的删除，只是做一个标记"）。
· restoreNode —— 撤销未成行（点错了能改回来）。
界面上的「彻底删除」与「标记未成行」是两个并列动作，弹窗文案里写明区别。
## 修正历史（Schema v19，新表 trip_node_revisions）
每次修正一行：实际起止 / 实际地点 / 说明 / 参与人快照。
第 1 条 = 原计划快照，第 2..n 条 = 各次修正 —— 详情页用表格展示，可直接对比。
## 日历与往年今日（用户点名的联动）
· 日历：`n.stage IN ('plan','actual')` —— 去掉旧的 `status<>'cancelled'`
（那是双轨口径；现在"未成行"是 stage）。实际行程标题加 ✓ 前缀便于区分。
· **活动本身绝不上日程**（用户："活动因为可能跨越的时间比较长"）。
· 往年今日：旅程部分从「整趟 events」改成**实际行程**（stage='actual'），
标题带活动名前缀；未成行的不出现。
## 验证
新增 _trip_e2e12.py **30/0**：建活动 → 加行程（可选计划/实际）→ 修正（仍计划 /
历史保留原计划 09:00 / 可无限次）→ 标记为实际 → 完成（无历史）→ 标记未成行（未真删）
→ 日历四种情形（已转实际✓ 新建实际✓ 完成✓ 未成行✗ 活动✗）→ 往年今日只看实际。
回归：e2e 787/0、升级 129/0（含 v19 路径）、batch_e 91/0、batch10 46/0、batch9 38/0、
picker 28/0 + 11/0、crop 17/0、formbloat 9/0、semi 27/0、geom 5/5、mobile 688/0、
interact 92/0、drag 5/0。
e2e 两条旧断言（"双轨两块/两轨各一条"）按重构语义更新为"三组渲染 / stage 各一条
+ category 与 stage 同步"。
部署断言新增 1 大组，含**反退化防线**：skipNode 若被改成 DELETE 立即变红。
线上自检 19/19；线上真实账号验收 16/0。
线上老数据迁移实测：#222 计划3+实际1、#221 实际4、#220 实际13 —— 一条没丢。
This commit is contained in:
+13
-3
@@ -744,15 +744,21 @@ final class Calendar
|
||||
// ⚠️ 别在 SQL 字符串里写 `--` 行内注释：PHP 里那段是普通字符串，
|
||||
// 但 `--` 之后的内容仍是字符串的一部分，SQL 侧被注释掉，
|
||||
// 而 PHP 侧语法检查看不出问题 —— 会变成"语句少半截"的静默错误。
|
||||
// v24 第 13 批（用户 2026-10-05）：旅程重构后，**按 stage 过滤**。
|
||||
// · plan → 上日程（用**计划**时间）
|
||||
// · actual → 上日程（时间已经是实际时间，因为"修正"会把实际值写回行程）
|
||||
// · skipped → **不上日程**（用户："就权当没有这个日程"）
|
||||
// ⚠️ 不能再按 status<>'cancelled' 过滤 —— 那是旧双轨的口径；
|
||||
// 现在"未成行"是 stage='skipped'，而 status 可能仍是 planned。
|
||||
$st = Database::get()->prepare(
|
||||
"SELECT n.id AS node_id, n.title AS node_title, n.starts_at, n.ends_at,
|
||||
n.node_type, n.status AS node_status,
|
||||
n.node_type, n.status AS node_status, n.stage AS node_stage,
|
||||
e.id AS event_id, e.title AS trip_title
|
||||
FROM trip_nodes n
|
||||
JOIN events e ON e.id = n.event_id AND e.kind = 'trip'
|
||||
LEFT JOIN trip_details d ON d.event_id = e.id
|
||||
WHERE n.family_id = ? AND n.starts_at IS NOT NULL
|
||||
AND n.status <> 'cancelled'
|
||||
AND n.stage IN ('plan','actual')
|
||||
AND COALESCE(d.is_public, 1) = 1
|
||||
AND DATE(n.starts_at) <= ? AND COALESCE(DATE(n.ends_at), DATE(n.starts_at)) >= ?
|
||||
ORDER BY n.starts_at"
|
||||
@@ -772,7 +778,11 @@ final class Calendar
|
||||
'cal' => (int)$c['id'],
|
||||
'color' => (string)$c['color'],
|
||||
'calname' => (string)$c['name'],
|
||||
'title' => Trip::typeIcon((string)$n['node_type']) . ' ' . (string)$n['node_title'],
|
||||
// 用户要"一眼看出这是计划还是实际"：实际行程加个 ✓ 前缀。
|
||||
// 计划行程保持原样（日历里大多数是它，加前缀反而吵）。
|
||||
'title' => Trip::typeIcon((string)$n['node_type'])
|
||||
. ((string)($n['node_stage'] ?? 'plan') === 'actual' ? ' ✓ ' : ' ')
|
||||
. (string)$n['node_title'],
|
||||
'date' => $day,
|
||||
'time' => $first ? ($tm === '00:00' ? '' : $tm) : '',
|
||||
// 结束时刻只落在节点跨天的最后一天（与自定义日程同一口径）
|
||||
|
||||
Reference in New Issue
Block a user