v24 第 6 轮：名册导入 / 两种备注 / 多段工作经历 / 家谱卡片与首字母检索修正
用户 2026-10-03 第二批（8 条）。逐条落点：
1. **名册导入**（新）：支持 **vCard 3.0/4.0（.vcf）** 与 **CSV/TSV**（中英文表头都认）。
新增 `app/ContactImport.php`（纯解析）+ `app/ContactImporter.php`（判重+落库）。
判重按 **手机号（哈希，精确）→ 姓名（大小写无关）**；命中已有的人**只补空字段，
绝不覆盖**（批量覆盖没法回退）。
解析上要处理的三件事都处理了：**折行接回**（长名字/地址会被按字节折断）、
转义还原（`\,` `\;` `\n`）、多值收全（TEL/EMAIL/ADR 可能出现多次）。
UTF-16/GBK 的 vcf 也认（手机导出的常见编码）。
2. 成员详情页：右上角「移除」→ **「返回」**（回名册）；「删除」移到页面**最下方**
（在「开通登录账号」下面），并改成 `<details>` 两步确认 + 写清会连带删掉什么。
3. 编辑资料里的「这个人的一句话」**去掉** —— 那句话只能**本人**改。
⚠️ 落法是「这一栏只在改自己时出现」：用户要的是"别人不能替他写"，
而不是"这句没人能填"；服务端也只在 `$isSelf` 时读表单，否则管理员一编辑就把它清空。
4. **工作单位 / 职务 / 职称可以有多段**（新表 `person_jobs`）：表单是一组"经历行"
（单位/职务/职称/起止年月/备注，可 ＋/×），详情页按"现在 + 历史"列出。
`persons.org/title` 保留，语义变成"当前那段的快照"（列表页等只要"现在在哪儿"），
升级时把老的 org/title 回填成一段经历。
5/备注分两种：「自我介绍」（`persons.note`，他本人写的、别人看得到）与
**「我对他的私人备注」**（新表 `person_notes`，每人每对象一条，**只有写的人自己看得到**）。
详情页有独立的一块；表单里只在"编辑别人"时出现。
6. 成员表单：**头像放到最前**、去掉「选择文件」按钮（点那张默认头像即选文件）；
表单标签统一 15px/600（原来 13–14px，和 12px 的灰字提示分不出层级）。
7. 名册列表：⋯ 前面加**「编辑」**按钮（改资料是高频动作，藏进 ⋯ 要点两下）。
8. 家谱：
· **首字母检索 bug**：输入 `yy` 会搜出「岳父/洪勇」。根因是前端把
**姓名与称呼的首字母拼成一串**再判子序列 —— 洪勇的称呼是"岳父" → `hy`+`yf`=`hyyf`
→ `yy` 跨字段命中。改成**逐字段独立判**（服务端本来就是逐字段判的，两边现在同口径）。
· **卡片仍比头像宽**：头像是 **1:1（正方形）** 槽位，卡片里却写成 96×72 的长方形 +
`object-fit: contain` → 照片被缩到 72 宽、左右各留 12px 白 → 看着"框比头像宽"。
改成**正方形头像区 + `object-fit: cover`**（90×128 卡片，88×88 头像区）。
· 右上角加**「我的家谱」**按钮（只在看别人的家谱时出现 —— 看自己的时候点它没意义）。
**测试新增**（都能变红，且做过反向验证）：
- `_fb_import_test.py` 21 条：新人新建 / 手机号命中不重复建人 / **已有字段一个都不被覆盖** /
缺的字段被补上 / 反复导入幂等 / 只给姓名也能命中 / 认不出的文件被明确拒绝，
外加 ⑱ **"有单位但没有经历行"的人**（最容易漏的覆盖路径）。
- `_fb_roster_filter_test.js`（jsdom，用真实渲染出的 HTML）8 条：直击
「输 yy 不该命中 岳父/洪勇」；反向验证时把实现改回拼接写法 → ① 立刻红。
- 改动过程中被测试抓出**两个真 bug**并已修：
① 导入时给"已有单位的人"也插经历 → `PersonJob::syncCurrent()` 回写把这人的单位**覆盖**了；
② `syncCurrent()` 在经历表为空时会把 `persons.org/title` **清空** ——
而它被"编辑资料"这类常规路径调用一次就触发，属于**随手一保存就丢数据**。
现在空表直接 return（"经历表不是唯一的一份"）。
**战绩**：e2e **775/0** · 导入 21/0 · 第 5 轮专项 91/0 · 家谱 34/0 · 几何 428/0 ·
移动端 688/0 · 交互 97/0 · 升级 126/0。
线上：schema **v15**、指纹一致、`person_jobs`/`person_notes` 已建、
6 条老的"工作单位"全部回填成经历、13 个文件 md5 与本地一致、错误日志无新增。
This commit is contained in:
+63
-3
@@ -71,7 +71,7 @@ final class Schema
|
||||
* ⚠️ 它**不再**作为"要不要跑升级"的判据 —— 见 fingerprint() 的说明。
|
||||
* 它仍然要手工维护，因为它给人看（排查时一眼知道代码到哪一版了）。
|
||||
*/
|
||||
public const VERSION = '14';
|
||||
public const VERSION = '15';
|
||||
|
||||
/**
|
||||
* 「源码指纹」：拿**本文件自身的内容**算一个哈希，作为"要不要跑升级"的判据。
|
||||
@@ -1035,8 +1035,68 @@ CREATE TABLE IF NOT EXISTS `ledger_shares` (
|
||||
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_unicode_ci COMMENT='账本共享'
|
||||
SQL);
|
||||
|
||||
// 被容错跳过的数据步骤记进设置，系统设置页会把它显出来 ——
|
||||
// 不然「升级没跑完」这件事只活在日志里，跟没发生一样。
|
||||
// ---- 工作经历（版本 15，用户 2026-10-03 第 4 条）----
|
||||
// 用户原话：「工作单位、职称、职务，都是可以填写多个的，因为一个人的工作可能会变，
|
||||
// 我们需要记住他工作和职务的变化。」
|
||||
// 于是一个人不再只有"一个单位 + 一个职称"，而是一串经历（见 App\PersonJob）。
|
||||
// ⚠️ persons.org / title **保留不动**，语义变成"当前那一段的快照"：
|
||||
// 名册/家谱/观影标签这些地方只要"现在在哪儿"，不该为一行字去 JOIN 历史表；
|
||||
// 而且老数据也不会因为这次改动而消失。
|
||||
$db->exec(<<<'SQL'
|
||||
CREATE TABLE IF NOT EXISTS `person_jobs` (
|
||||
`id` INT UNSIGNED NOT NULL AUTO_INCREMENT,
|
||||
`person_id` INT UNSIGNED NOT NULL,
|
||||
`org` VARCHAR(120) DEFAULT NULL COMMENT '单位',
|
||||
`title` VARCHAR(120) DEFAULT NULL COMMENT '职务（如 主任 / 副院长）',
|
||||
`rank_name` VARCHAR(120) DEFAULT NULL COMMENT '职称（如 副教授 / 高级工程师）',
|
||||
`start_ym` CHAR(7) DEFAULT NULL COMMENT '起始年月 YYYY-MM（可空）',
|
||||
`end_ym` CHAR(7) DEFAULT NULL COMMENT '结束年月；**空 = 现在还在**（列表里标「现在」）',
|
||||
`note` VARCHAR(200) DEFAULT NULL,
|
||||
`created_at` DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP,
|
||||
PRIMARY KEY (`id`),
|
||||
KEY `idx_pj_person` (`person_id`, `end_ym`),
|
||||
CONSTRAINT `fk_pj_person` FOREIGN KEY (`person_id`) REFERENCES `persons` (`id`) ON DELETE CASCADE
|
||||
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_unicode_ci
|
||||
COMMENT='工作经历：一个人可以有多段（单位/职务/职称/起止年月）'
|
||||
SQL);
|
||||
|
||||
// 升级回填：老数据只有 persons.org / title 两个字段 → 造一段"没有起止"的当前经历。
|
||||
// ⚠️ 只在**这个人还没有任何经历**时补，重复跑不会重复插（幂等）。
|
||||
try {
|
||||
$db->exec(
|
||||
'INSERT INTO person_jobs (person_id, org, title, rank_name, start_ym, end_ym, note)
|
||||
SELECT p.id, p.org, p.title, NULL, NULL, NULL, NULL
|
||||
FROM persons p
|
||||
WHERE (p.org IS NOT NULL AND p.org <> "" OR p.title IS NOT NULL AND p.title <> "")
|
||||
AND NOT EXISTS (SELECT 1 FROM person_jobs j WHERE j.person_id = p.id)'
|
||||
);
|
||||
} catch (\Throwable $ex) {
|
||||
self::$stepErrors[] = '工作经历回填：' . $ex->getMessage();
|
||||
}
|
||||
|
||||
// ---- 「我对他的备注」（版本 15，用户 2026-10-03 第 5 条）----
|
||||
// 用户原话：「名册中，每个人的备注，都有两个，一个是他自己填写的，就好像他自己的
|
||||
// 一个格言或者自我介绍；如果其他人打开这个人的信息，编辑备注，
|
||||
// 是这个人对他的独有的备注，例如记录怎么跟这个人认识的等等。」
|
||||
//
|
||||
// 所以两种备注分开放：
|
||||
// · persons.note —— **本人写的**自我介绍（每个人自己一份，见 form 的说明）；
|
||||
// · person_notes —— **"我"对他写的**私人备注（每人每对象一份，别人看不到）。
|
||||
// ⚠️ 不塞进 persons：那是"一个人的属性"，而"我怎么认识他的"是**我和他之间**的事，
|
||||
// 混在一起必然出现"我把备注写在别人身上、全家都看得见"。
|
||||
$db->exec(<<<'SQL'
|
||||
CREATE TABLE IF NOT EXISTS `person_notes` (
|
||||
`person_id` INT UNSIGNED NOT NULL COMMENT '被写备注的那个人',
|
||||
`viewer_id` INT UNSIGNED NOT NULL COMMENT '谁写的（只有他自己看得到）',
|
||||
`note` TEXT DEFAULT NULL COMMENT '我对他的私人备注（怎么认识的、要注意什么…）',
|
||||
`updated_at` DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP,
|
||||
PRIMARY KEY (`person_id`, `viewer_id`),
|
||||
CONSTRAINT `fk_pn_person` FOREIGN KEY (`person_id`) REFERENCES `persons` (`id`) ON DELETE CASCADE,
|
||||
CONSTRAINT `fk_pn_viewer` FOREIGN KEY (`viewer_id`) REFERENCES `persons` (`id`) ON DELETE CASCADE
|
||||
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_unicode_ci
|
||||
COMMENT='「我对某个人的私人备注」：每人每对象一条，只有自己看得到'
|
||||
SQL);
|
||||
|
||||
// ---- 账本盘点（版本 14，用户 2026-10-03 第 8 条）----
|
||||
// 用户原话：「账本要增加盘点功能，因为某一个账目可能会变，要记住每一次变化，
|
||||
// 用盘点来完成。我点击盘点，让我对一个账目的金额进行重新输入，
|
||||
|
||||
Reference in New Issue
Block a user