3 Commits

Include renames

Author	SHA1	Message	Date
tamakyi	496c992e5e	图片不再随数据集删除：加「图片挂载恢复」，place_images 摘掉外键 ... 用户报「之前上传的照片找不到了，应该是因为清了应用数据换基线」。查下来与 App 侧无关， 是站点自己两套口径打架： - place_images.dataset_id 带 ON DELETE CASCADE，而读取按 place_key 坐标键、跨数据集。 - 于是删掉旧数据集时图片**行**被级联删了，**文件却留在 media 目录里**。 - 实测（本机）：datasets 只剩 155 号、place_images 0 行、盘上 4 个 .webp 好端端躺着。 同一批附属数据里备注（17）与结论（3+1）因为早就迁到坐标键，毫发无损——只有图片倒霉。 三件事： 1) 恢复：后台首页「图片挂载恢复 → 扫描并恢复」（POST /admin/images/recover， internal/web/image_recovery.go）。只插行、不删文件、不看数据集，按 object_key 判重可反复点。 认地点两处来源：数据集还在就查它的 places；数据集已删就读它留下的 baselines/<id>.sqlite 还原「地点号 → 坐标」。对象键两种历史布局都认（<ds>/<YYYYMM>/<srcPK>-<hash>.webp 与 <ds>/<srcPK>/<hash>.webp）；判据先看文件名有没有 `<数字>-` 前缀，再看中间目录—— 地点号也可能刚好 6 位，只看位数会认错。 2) 防复发：CREATE TABLE place_images 去掉外键 + 幂等 DROP CONSTRAINT；删图接口不再按 dataset_id 过滤（数据集删了也得能删图）；「删除数据集」的二次确认文案改成实话。 3) 报告同类陷阱（未改）：topics 仍带 CASCADE，专题随数据集一起删且没有恢复来源。 测试踩到的坑：图片「按坐标键跨数据集读」+「按 object_key 判重」都不看数据集，用例之间会 互相污染两处——盘上文件（报「应当 2 张、实际 10 张」）与库里的行（Already:1 让兜底分支 根本没跑到，用例差点假绿）。加 isolateImageState（换空 DataDir + 按 place_key 清历史行）， 并给夹具补收尾清理（外键没了必须自己清）。 新增用例 4 条；验收：./scripts/verify.sh 全量 PASS=323 FAIL=0 SKIP=0。	2026-09-30 19:45:51 +08:00
tamakyi	86e420bd4e	新建地点的活动下拉可即时新增，地点行内编辑支持批量改该地点全部到访的活动 ... 站长反馈「已有地点编辑和新建里只有类别没有活动能选」。实测澄清：新建地点卡一直有活动下拉， 只是形态与类别/照片页不一致（旁边常显一个新建框、下拉里没有「＋ 新增活动…」）；真正完全没有 活动字段的是地点列表行的「编辑」。 - 新建地点卡：活动下拉补「＋ 新增活动…」哨兵，旁边的新建框改成选中哨兵才展开； 删掉原来那对 #activity-add/#new-activity-name 监听——三处活动下拉现在共用同一套 `visit-act-*` 委派处理器，重复监听会建出两条活动。 - 地点行内编辑：加「活动（改该地点全部到访）」下拉，默认「（不修改）」不预选当前值 （否则每次改坐标保存都会重写历史到访的类型），并标出当前类型构成；选了真实活动时 提交前 confirm 一次。 - 服务端（places 没有活动列，活动挂在到访上）：editPlaceUpdate 解析 activity_id，空值=不修改， 与地点行同一事务内 UPDATE visits 的 activity_id/is_home/is_work，flash 报改了几条； 哨兵值/不存在的 id/别的数据集的活动一律拒。导出无需改动（ZVISIT.ZACTIVITY_ 本就是管理列）。 - 回归 internal/web/place_activity_test.go：批量改（含别的地点不受影响）、空值不修改、越权被拒、 模板契约、以及导出包里那批到访的 ZACTIVITY_ 必须换成新活动的 rond 编号。 - 顺手：TestMovementCleanExport 建出 ROND_CLEAN_OUT 的父目录，别再把「目录不存在」报成导出失败。	2026-09-18 21:23:13 +08:00
tamakyi	b327bc1230	first release	2026-09-18 13:05:49 +08:00