文睿 张
|
838889ce9f
|
feat: 按公司隔离物料主数据
|
2026-10-09 10:38:02 +08:00 |
|
文睿 张
|
8f4460b84a
|
feat: 强制校验可信公司上下文
|
2026-10-09 09:56:21 +08:00 |
|
文睿 张
|
696e90893b
|
fix: 主数据编辑的两类静默失败
UPDATE 漏列：
- code_rules 的 SET 补上 category_id。此前改分类提示"保存成功"但不落库，
是唯一用户可达的活缺陷（同页的分类下拉没有 disabled，且规则只能改不能删，
没有"删了重建"这条退路）
- code_rules 有 uk_code_rules_org_category，补列后改到已占用的分类会撞唯一键，
新建与更新统一翻成中文的 ErrDuplicateCodeRule
- 分类/单位/仓库/库位/伙伴的编码定为不可变：分类编码是编码规则前缀的来源
（init.sql 的种子数据直接取 material_categories.code），伙伴编码是对外业务
编号，改掉会让历史数据脱节且查不回来。service 的 Update* 不再要求编码非空
——原先是"必须传、传了却被丢弃"；新建侧的必填校验保留
- 顺带补齐两处同款漏网：organization.go 的 code 与 partner.go 的 partner_code
（前者 service 本就不校验编码，自洽，无需改）
记录不存在时的静默成功：
- DSN 开启 clientFoundRows，让 RowsAffected 返回"匹配"行数而非"实际改变"行数。
否则"编辑时一个字段都没改"和"记录不存在"都返回 0，无法区分，直接加检查会把
正常保存误判成记录不存在（真 MySQL 8.0 实测）
- 新增 repository.execExpectingRow，7 个 Update* 影响 0 行时返回 ErrRecordNotFound；
伙伴走事务内的 SELECT ... FOR UPDATE，只需翻译 sql.ErrNoRows
- 既有 4 处 RowsAffected 用法逐处核对过，均不受该 flag 影响
测试：补 6 个 Update* 的存在性检查、编码必填约束的两端、唯一键翻译、DSN 拼接；
全部做过变异验证（抽掉实现后对应测试确实变红）。
|
2026-09-21 17:26:53 +08:00 |
|
文睿 张
|
72bc6c9af2
|
test: 补齐 Update 的 happy-path 用例，锁定「编辑走 UPDATE」而非 INSERT
六个 Update* 此前只有 UpdateRequiresID 覆盖到拒绝分支，方法体里的
s.repo.Update*(item) 从未被执行。这 12 个方法互为复制粘贴的模板，
尾行一旦误写成 Create* 全部测试仍然绿灯，生产行为会退化成「编辑即新增」。
新增两条用例：PartnerService.Update（事务：SELECT ... FOR UPDATE + 两条
UPDATE）与 MasterDataService.UpdateCategory（单条 UPDATE），均登记
UPDATE 期望并以 ExpectationsWereMet 兜底。把尾行改成 Create* 实测两条
用例都会失败并指名收到了 INSERT。
同时 gofmt internal/service/admin_master.go：新增中文注释紧贴前一个函数的
}，补上缺失的空行，纯空白改动。
|
2026-09-21 15:34:41 +08:00 |
|
文睿 张
|
6ed205dcb8
|
refactor: 拆分 WarehouseService 的 Create/Update，去掉 ID==0 猜分支
|
2026-09-21 15:09:37 +08:00 |
|
文睿 张
|
16ca9c02ba
|
refactor: 拆分 MasterDataService 的 Create/Update，分类与单位创建不再受脏 id 影响
|
2026-09-21 15:03:57 +08:00 |
|
文睿 张
|
1b0cdde780
|
refactor: 拆分 PartnerService 的 Create/Update，创建接口不再被脏 id 带偏
|
2026-09-21 14:59:01 +08:00 |
|