20260911173133

This commit is contained in:
oneao committed 2026-09-11 17:31:34 +08:00
1 parent 3838ed74b1
commit f3ad727f1c
60 files changed
+4971 -6621

No files matched your search

@@ -0,0 +1,728 @@
# 历史记录选择器配置设计讨论
## 一、这份设计要解决什么问题
业务页面经常需要从以前的单据中找一条或几条记录,然后带回当前页面。例如:
- 从以前的业务单中选择发货人;
- 从以前的业务单中选择收货人或通知人;
- 从以前的费用记录中选择费用,加入当前费用明细;
- 从以前的业务单中选择箱子、货物等子表数据。
现在每个页面都自己写一个弹窗,自己拼查询 SQL,自己决定选中后怎么回填。这样做有几个明显问题:代码重复,字段改名后容易出错,同一套功能不能复用,业务人员也不能只通过配置调整规则。
这次希望把它做成一个通用能力:
```text
业务动作配置 + 通用选择器 + 字段映射
```
简单说就是:
- 通用选择器只负责“查数据、让用户选择”;
- 动作配置负责“查哪个模块、固定过滤什么、选中后写到哪里”;
- 业务页面只提供当前表单数据,并接收选择结果,最后仍由页面统一保存。
## 二、整体使用方式
在模块管理中增加“动作”页签。例如,在 `bs_business` 模块下配置:
```text
选择历史发货人
选择历史收货人
选择历史通知人
选择历史费用
```
业务页面加载当前模块的动作配置,由页面自己决定按钮放在哪里、什么时候显示。点击业务页面上的按钮后,打开统一组件:
```text
src/components/fms-record-picker/FmsRecordPickerModal.vue
```
页面只需要告诉组件:
```text
动作编码:select_history_shipper
当前主表数据
当前正在编辑的子表行(如果有)
当前页面已经存在的目标数据
```
页面不再传 `wheresql`,也不再自己拼接 SQL。
### 配置入口放在哪里
动作配置放在现有的**模块管理页面**中,不另外新建一个独立的配置页面。
使用方式是:
```text
模块管理
→ 选择目标模块:cw_business
→ 动作
├─ 选择历史费用
├─ 选择历史发货人
└─ 选择历史收货人
```
这样做是因为动作属于目标业务模块:它描述的是“当前模块可以执行什么选择和回填操作”。在这里配置动作编码、来源模块、选择方式、是否允许重复以及字段映射等内容即可。
弹窗中让客户填写的查询条件,仍然配置在**来源模块**的“查询”页签中:
```text
模块管理
→ 选择来源模块:cw_business_history
→ 查询
├─ 业务单号
├─ 发货人
├─ 发生日期
└─ 状态
```
两者的职责要分开:
```text
目标模块 → 动作页签 → 配置从哪里选择、选中后写到哪里
来源模块 → 查询页签 → 配置弹窗中客户可以填写哪些筛选条件
```
按钮放在主工具栏、子表工具栏还是字段旁边,由业务页面代码决定,不在模块管理中配置。这样可以复用模块管理现有结构,又不会把页面布局做成低代码配置。
## 三、动作配置写什么
### 1. 基本信息
```text
动作编码:select_history_shipper
动作名称:选择历史发货人
动作类型:copy
启用状态:启用
排序号:10
```
动作编码必须稳定。它用于程序识别、配置导入导出和不同环境之间迁移,不能随意修改。
### 2. 从哪里选择
```text
来源模块:bs_business_history
选择模式:单选 / 多选
```
来源模块直接复用已有模块元数据:
- 列表默认显示 `s_field_view`;
- 查询条件默认使用 `s_field_query`;
- 字段标题、类型和格式使用 `s_field`。
动作不新建模块,也不复制一套字段定义。它只在来源模块的基础配置上,引用并裁剪本次选择器需要的展示列和查询项。
动作可以配置:
```text
展示列模式:inherit / explicit
查询条件模式:inherit / explicit
```
含义如下:
- `inherit`:沿用来源模块启用的 `s_field_view` 或 `s_field_query`;
- `explicit`:只使用动作配置中明确引用的展示列或查询项;
- `explicit` 且没有配置项:表示本动作明确不提供对应的展示列或用户查询项,不能再解释为“继承默认配置”。
动作字段配置只保存对既有配置的引用,不重新定义字段名称、类型、权限和操作符。来源模块仍然是字段定义的唯一来源。
## 四、单选、多选和重复选择是三件事
这三个概念不能混在一起:
```text
选择模式 一次点击“确定”可以选几条
重复选择策略 同一条来源记录以后能不能再加入
去重标识 系统凭什么判断两次选择的是同一条记录
```
动作配置建议增加以下内容:
```text
选择模式:single / multiple
重复选择策略:forbid / allow
重复时处理:skip / warn / error
去重字段:来源模块的稳定主键
```
含义如下:
- `single`:一次只能选一条;
- `multiple`:一次可以选多条;
- `forbid`:已经加入过的来源记录,之后不能再次加入;
- `allow`:允许再次打开选择器并再次加入同一条来源记录;
- `skip`:重复记录直接跳过;
- `warn`:提示用户后跳过;
- `error`:发现重复就不允许确认。
默认建议:
```text
pick / copy single + forbid + error
append / replace multiple + forbid + warn
```
只有业务明确允许重复时,才配置 `allow`。
要注意:`allow` 是指“以后可以再次选择”,不表示一次确认时可以把同一行选两遍。若要一条记录生成多行,应另加数量或复制次数功能,不放进选择器的基本选择逻辑里。
### 去重必须有稳定的来源 ID
不能用表格行号判断重复,也不能只比较名称、编码等容易重复的字段。应使用来源模块的稳定主键,例如 `b_id` 或 `subid`。
如果目标是子表,建议把来源主键保存到目标子表的隐藏字段中:
```text
来源 subid → 目标 mx_source_subid
```
这个隐藏字段不显示给用户,但用于:
- 再次打开选择器时排除已经选过的数据;
- 防止分页或重复打开造成重复加入;
- 追踪当前行来自哪条历史记录;
- 后续撤销、同步和问题排查。
## 五、查询条件怎么设计
查询条件分两部分:
### 查询条件到底配置在哪里
客户在选择器中看到并填写的查询项,基础配置仍然来自**来源模块**的 `s_field_query`(模块管理中的“查询”页签)。动作可以选择直接继承,也可以通过动作查询配置引用其中的子集。
例如来源模块 `bs_business_history` 的“查询”页签配置了:
```text
业务单号:包含
发货人:包含
发生日期:日期范围
客户:下拉选择
```
打开 `FmsRecordPickerModal` 时,后端先按动作的 `b_query_mode` 解析有效查询项,再返回给组件渲染。客户填写后点击“查询”,这些条件只影响本次弹窗的数据列表。
动作配置中的 `s_module_action_filter` 是另一回事。它保存的是动作必须带上的固定条件,客户看不到,也不能修改,例如“只能查当前客户的历史记录”。
可以这样理解:
```text
s_field_query 客户可以填写的查询条件
s_module_action_filter 系统强制追加的固定条件
```
最终查询是两者合在一起:
```text
来源模块查询条件 AND 动作固定条件
```
动作查询配置只引用来源模块已有的 `s_field_query` 记录,不复制字段定义或查询语义。这样同一个来源模块可以支持多个选择器动作,每个动作使用不同的查询项集合。
例如:
```text
来源模块查询配置:业务单号、发货人、收货人、客户、发生日期、状态
选择历史发货人:业务单号、发货人、发生日期
选择历史收货人:业务单号、收货人、发生日期
选择历史费用:费用名称、发生日期、币种、状态
```
动作固定条件不进入用户查询区。用于固定过滤、去重和关联的技术字段可以不显示,也不能作为用户临时查询项。
### 1. 动作固定条件
这是动作本身规定的条件,用户不能修改。例如“选择历史费用”只能查同一个客户、同一种费用类型:
```text
历史费用.客户 = 当前主表.客户
历史费用.费用类型 = 当前操作的费用类型
历史费用.来源单据 ID != 当前单据 ID
```
### 2. 用户临时查询条件
这是用户在弹窗中输入的条件,例如费用名称、日期、状态、编码等。动作使用 `inherit` 时复用来源模块的 `s_field_query`;使用 `explicit` 时只显示动作引用的查询项,控件和操作符仍由被引用的来源查询配置决定。
例如来源模块配置了:
```text
费用名称:包含
发生日期:日期范围
币种:下拉选择
```
选择器按动作的有效查询项显示这些查询控件。用户点击查询后,条件和动作固定条件一起生效。
### 3. 前端只传结构化条件,不传 SQL
前端请求示例:
```json
{
"actionCode": "select_history_fee",
"context": {
"main": {
"b_customer_id": 8,
"b_id": 125
},
"detail": {
"mx_type_id": "应收"
}
},
"query": {
"page": 1,
"pageSize": 20,
"conditions": [
{
"fieldId": 610,
"operator": "like",
"value": "海运"
},
{
"fieldId": 611,
"operator": "gte",
"value": "2026-01-01"
}
]
}
}
```
前端和数据库配置中都不出现 SQL。后端根据字段 ID、操作符和字段类型生成参数化查询。
### 4. 动作条件的值从哪里来
建议支持以下值来源:
```text
current.main.field 当前主表字段
current.detail.field 当前子表字段
constant 固定值
user.id 当前用户
user.orgId 当前机构
today 当前日期
```
例如:
```text
来源字段:mx_dw_id
操作符:等于
值来源:current.main.field
当前字段:b_customer_id
```
运行时就是“来源记录的 `mx_dw_id` 等于当前主表的 `b_customer_id`”。
### 5. 空值不能被悄悄忽略
如果当前客户还没有填写,不能因为值为空就直接删掉“客户相等”这个条件,否则可能查出所有客户的历史记录。
每个固定条件建议配置空值处理方式:
```text
reject 不允许打开选择器,并提示先填写条件
empty 返回空结果
is_null 按 IS NULL 查询
ignore 忽略这个条件(只对明确允许的场景使用)
```
历史记录选择默认使用 `reject` 或 `empty`。
### 6. 条件组合
第一阶段只支持多个条件之间使用 `AND`,已经可以覆盖大部分历史记录场景:
```text
客户相同 AND 当前单据不同 AND 费用类型相同
```
以后确实需要时,再增加条件组和 `OR`。不要一开始就允许用户输入任意 SQL 或任意表达式。
## 六、字段映射怎么设计
选中的来源字段和目标字段不一定同名,所以要配置映射。例如选择历史发货人:
```text
来源字段 目标字段
b_shipper b_shippermemo
b_shipper_contact b_shipper_contact
b_shipper_phone b_shipper_phone
b_customer_id b_customer_id
```
选择历史费用并追加到费用子表:
```text
来源 b_fee_code → 目标 b_fee_code
来源 b_fee_name → 目标 b_fee_name
来源 b_amount → 目标 b_amount
来源 b_currency → 目标 b_currency
来源 subid → 目标 mx_source_subid(隐藏去重字段)
```
映射配置应从源模块和目标模块的字段元数据中选择字段,保存字段 ID,不让用户手工填写字段名。
字段映射不是新的字段定义。来源字段和目标字段都必须引用现有 `s_field`,字段名称、类型、可空性、写入模式和启用状态始终以 `s_field` 为准。
每条映射还可以配置:
```text
目标范围:主表 / 子表
写入方式:覆盖 / 追加 / 合并
转换方式:原值 / 数字 / 日期 / 拼接
是否必需:是 / 否
是否为去重字段:是 / 否
```
如果目标是子表,运行时根据 `s_relation` 自动补齐父 ID、临时 ID 和排序号。目标字段的只读、计算、系统字段规则仍然有效,不能通过动作配置绕过。
动作配置只能缩小字段范围,不能提升字段权限。运行时的有效字段按以下规则计算:
```text
可展示/可查询来源字段
= 动作引用的字段
∩ 来源模块中存在且启用的字段
∩ 当前用户拥有 view 权限的字段
可写目标字段
= 动作映射的字段
∩ 目标模块中存在且启用的字段
∩ 当前用户拥有 edit 权限的字段
∩ s_field.b_writemode 允许写入
```
固定过滤字段、去重主键和关系父 ID 等技术字段可以不展示给用户,但后端只能将它们用于动作执行,不能因为动作配置而把它们作为普通可见字段返回。
## 七、重复选择的运行规则
系统需要同时考虑三种“已经选过”的数据:
```text
本次弹窗已经选过的记录
当前页面草稿中已经存在的记录
数据库中已经保存的关联记录
```
当动作配置为 `reselectPolicy = forbid` 时,这三类记录都应显示为“已选择”并禁用,而不是简单从表格中删除。这样用户知道它们存在,也知道为什么不能选。
确认时还要再次检查重复,不能只依赖前端界面:
```text
用户点击确定
↓
系统根据去重字段重新检查
↓
按 skip / warn / error 处理
↓
生成最终的回填结果
```
当配置为 `allow` 时,同一来源记录可以再次生成新的目标行;系统不自动去重,但仍应保留来源 ID,方便追踪。
## 八、动作类型
动作类型先定义为有限集合;第一阶段只落地 `copy` 和 `append`:
```text
pick 选择一条记录,返回关联值
copy 选择一条记录,复制到当前主表
append 选择多条记录,追加到目标子表
replace 选择多条记录,替换目标子表(后续阶段)
```
不要一开始支持任意脚本或任意客户端函数。遇到特殊转换时,增加明确命名的转换类型或受控处理器。
## 九、建议的数据表
第一版使用规范化配置表,不把所有内容塞进一个 JSON 字段。
### `s_module_action`
保存动作基本信息:
```text
b_id
b_code 动作编码
b_name 动作名称
b_module_id 目标模块
b_action_type pick/copy/append/replace
b_source_module_id 来源模块
b_target_module_id 结果写入的目标模块;写入当前主表时可等于目标模块
b_target_relation_id 主表到目标子表的关系;写入主表时为空
b_selection_mode single/multiple
b_reselect_policy forbid/allow
b_duplicate_behavior skip/warn/error
b_dedupe_field_id 来源去重字段
b_view_mode inherit/explicit
b_query_mode inherit/explicit
b_canuse
b_xh
```
`b_target_scope = main/detail` 不足以表达一个模块有多个子表,因此使用目标模块和目标关系确定写入位置。`b_view_mode` 与 `b_query_mode` 用于区分“未配置,继承来源模块”和“明确配置为空,不显示/不提供查询项”。
### `s_module_action_filter`
保存动作固定过滤条件:
```text
b_id
b_action_id
b_source_field_id
b_operator
b_value_type
b_value_field_id
b_value_text
b_empty_behavior reject/empty/is_null/ignore
b_logic_group 第一阶段可固定为 0
b_logic_operator 第一阶段固定为 AND
b_xh
```
### `s_module_action_column`
保存动作引用的展示列:
```text
b_id
b_action_id
b_source_field_view_id 引用来源模块的 s_field_view
b_visible
b_xh
b_width_override
```
动作使用 `explicit` 模式时,只显示被引用的 `s_field_view`;`inherit` 模式下直接使用来源模块的 `s_field_view`。动作不复制字段定义、字段标题或字段权限。
### `s_module_action_query`
保存动作引用的用户查询项:
```text
b_id
b_action_id
b_source_field_query_id 引用来源模块的 s_field_query
b_visible
b_xh
```
动作使用 `explicit` 模式时,只显示被引用的 `s_field_query`;`inherit` 模式下直接使用来源模块的 `s_field_query`。查询字段的类型和操作符以被引用的来源查询配置为准,第一版不在动作表中重复定义。
### `s_module_action_mapping`
保存选择结果的字段映射:
```text
b_id
b_action_id
b_source_field_id
b_target_module_id
b_target_field_id
b_write_mode
b_transform
b_required
b_is_dedupe_key
b_xh
```
### 动作配置与字段权限的关系
动作定义和权限定义分开保存:
```text
s_module_action
描述动作如何查、如何选、如何映射
s_power
b_power_type = action
描述谁可以执行这个动作
```
动作编码使用目标模块编码和动作编码组成稳定身份,例如:
```text
cw_business.select_history_fee
```
对应的 `s_power` 动作权限使用目标模块作为 owner,生成类似 `action.module.cw_business.select_history_fee.execute` 的全局唯一业务键,能力为 `execute`。动作配置不能绕过 `s_power`,字段策略也不能被动作配置提升。后端必须同时校验动作执行权限、来源字段最终为 `view` 或 `edit`、以及目标字段最终为 `edit`。
来源字段被停用、删除或当前用户无权查看时,动作应在配置校验或运行时被判定为无效,不能静默删掉映射项继续执行。
## 十、运行时流程
```text
业务页面加载目标模块动作配置
↓
业务页面上的按钮打开 FmsRecordPickerModal,并传入当前表单上下文
↓
解析动作的展示列模式和查询条件模式,引用来源模块配置的对应子集
↓
解析动作固定条件
↓
合并用户输入的查询条件
↓
按分页查询并显示“已选择/可选择”状态
↓
用户选择一条或多条记录
↓
检查重复选择和必填映射
↓
根据 mapping 生成主表 patch 或子表新行
↓
回写当前页面草稿
↓
由页面统一 handleSave()
```
选择器不负责保存数据库。映射结果先进入当前页面的草稿、diff 和校验流程,和手工新增的数据一样,最后统一保存。
建议选择确认事件返回记录或 patch,不返回 SQL。客户端确认时只提交来源记录的稳定主键,后端重新读取来源记录并生成 patch:
```json
{
"actionCode": "select_history_fee",
"rows": [
{
"subid": "fee-001",
"mx_fee_code": "F001",
"mx_fee_name": "海运费",
"mx_amount": 1200
}
],
"patch": {
"detailRows": [
{
"mx_source_subid": "fee-001",
"mx_fee_code": "F001",
"mx_amount": 1200
}
]
}
}
```
页面通常只需要把 `patch` 合并到草稿;`rows` 可用于提示、审计或特殊业务处理。
## 十一、组件和后端各自负责什么
### `FmsRecordPickerModal`
- 显示弹窗、查询区、表格和分页;
- 使用来源模块元数据渲染查询项和展示列;
- 显示哪些记录已选择;
- 管理本次操作中的选中状态;
- 返回用户选择的记录或动作执行结果。
### 动作执行器(建议放在后端或独立服务层)
- 读取并校验动作配置;
- 解析动作专用展示列和查询项,并与来源模块配置做一致性校验;
- 校验用户对来源模块的访问权限;
- 校验当前用户是否拥有动作对应的 `s_power` 执行权限;
- 校验来源字段 `view` 权限、目标字段 `edit` 权限和字段写入模式;
- 解析当前主表、子表、用户和日期等值来源;
- 校验字段 ID、目标模块和操作符;
- 生成参数化查询;
- 根据选中的来源主键重新读取来源数据;
- 执行去重检查和字段映射。
### 业务页面
- 提供当前页面上下文;
- 接收 patch 并更新草稿;
- 执行页面自己的计算和校验;
- 通过统一的保存流程提交。
## 十二、安全和校验要求
- 来源模块必须通过当前用户权限校验;
- 动作必须通过对应的 `s_power` `execute` 权限校验;
- 后端不能信任前端传来的任意字段、任意 SQL 或任意脚本;
- 过滤条件必须使用字段 ID、操作符和值的结构化表达;
- 后端按字段类型限制可用操作符;
- 动作展示列和查询项只能引用来源模块中存在且启用的 `s_field_view` / `s_field_query`;
- 动作配置只能缩小来源模块字段范围,不能提升字段 `view` / `edit` 权限;
- 映射目标必须属于目标模块或目标子模块;
- `readOnly`、`computed`、`system` 字段的写入规则继续生效;
- 来源字段删除或停用后,动作配置显示为无效并禁止启用;
- 配置导入导出使用动作编码和关系编码,运行时再解析内部 ID;
- 数据库配置中不保存可执行的任意 JavaScript;
- 确认时重新检查权限、字段合法性和重复记录,不能只依赖前端禁用状态。
## 十三、建议的实施顺序
### 第一阶段:先做通用选择器
先用内存中的声明式配置验证:
- 来源模块加载;
- 复用默认列表列和查询字段;
- 单选、多选;
- 动作固定过滤条件;
- 当前主表字段取值;
- 主表字段映射;
- 子表追加;
- `forbid` 和 `allow` 两种重复选择策略;
- 动作展示列和查询条件的 `inherit / explicit` 两种模式;
- 来源字段和目标字段权限交集校验;
- 分页和重新打开弹窗后的已选状态。
### 第二阶段:增加数据库配置
增加以下表和模块管理中的“动作”页签:
- `s_module_action`;
- `s_module_action_filter`;
- `s_module_action_column`;
- `s_module_action_query`;
- `s_module_action_mapping`。
动作列和动作查询项只引用来源模块已有的 `s_field_view` / `s_field_query`,不复制字段定义。同步增加动作配置的启用校验、字段权限校验和无效字段提示。
### 第三阶段:迁移业务操作
优先实现:
1. 选择历史发货人;
2. 选择历史收货人;
3. 选择历史通知人;
4. 选择历史费用;
5. 选择箱子或其他业务子表记录。
`replace`、复合去重键、`OR` 条件和自定义脚本转换不作为第一阶段的必要能力。迁移完成后,删除页面中按业务名称编写的专用选择弹窗和字段匹配代码。
## 十四、已确定和仍需确定的事项
### 已确定
- 来源模块是数据、字段和基础查询配置的唯一来源,不为每个选择器复制模块;
- 动作只引用并裁剪来源模块已有的 `s_field_view` / `s_field_query`;
- 动作展示列和查询项通过 `inherit / explicit` 明确区分继承和显式空配置;
- 字段权限由 `s_user_field_permission` 的 `hidden/view/edit` 策略统一控制,动作配置不能提升权限;
- 动作执行权限使用独立的 `s_power` `action/execute` 权限;
- 第一版优先实现 `fill/copy` 和 `append`,`replace` 延后;
- 固定过滤、去重和关系字段可以隐藏,但不能作为普通可见数据返回前端。
### 仍需确定
- `append` 追加时重复记录默认采用 `warn + skip`,还是直接阻止确认;
- `replace` 后续是否保留被替换行的来源关系;
- 是否允许复合去重键,而不只是单个稳定主键;
- 特殊字段转换是否需要受控的转换器注册表;
- 是否需要动作配置的预览和测试执行功能;
- 来源模块为视图且 `b_keyfield` 不可靠时,是否允许配置受控的复合稳定键;
- 业务页面是否允许少量自定义动作插槽。
## 十五、一句话总结
把“历史记录选择”当成一种可配置的业务动作:来源模块负责数据和字段定义,动作决定本次选择器展示哪些列、提供哪些查询项、怎么筛、能不能重复选以及选中后写到哪里;字段权限和动作执行权限由权限模型统一校验;通用选择器负责展示和选择;业务页面只接收结果并统一保存。这样无需为不同选择器复制模块,也能避免页面代码里出现 SQL 拼接和隐含的字段对应关系。