筛选条件怎么保存？个人视图与共享规则

保存筛选条件，应把当前查询整理成有名称的视图，并说明保存哪些条件、谁能使用、谁能修改。视图再次打开时会按条件查询当前数据，不一定返回第一次看到的那批记录。修改已有视图后，要让用户明确选择覆盖原视图或另存，不能在不知情时改变同事的工作入口。

以客服工单“本周未分配”为例，先画出创建、临时修改、保存与共享的路径，再用Pixso的原型设计与预览检查：客服能否知道当前用的是哪份视图，哪些条件还没有保存。

先约定一份视图包含什么

“本周未分配”包含创建时间为本周、处理人为未分配两个条件。本例还保存按创建时间从早到晚排序，但不保存当前页码、已勾选的工单和临时输入的备注。这些边界应由任务决定，不能把页面此刻的全部状态都塞进一个保存按钮。

若产品确实把列配置也纳入视图，保存确认中就要说明。关键不在于功能越少越好，而在于用户能预测下次打开会恢复什么。

“本周”不是第一次保存时的七个日期

客服希望每周都使用同一入口，所以“本周”应作为相对条件保存。到下一周再次打开，它按已约定的业务时区重新计算范围；如果保存的是10月5日至11日，就应明确显示固定日期，不能继续把它叫作会自动变化的“本周”。

同样，“由我负责”与“由李明负责”也有不同含义。前者通常随查看者变化，后者绑定具体人员。共享视图如果包含“由我负责”，不同成员看见的记录可以不同，但条件说明必须让人理解这个差别。不要因为记录数量不一致，就用一个错误提示把正常差异当成故障。

日期范围还涉及结束边界、自然日与时区，具体规则可接着看日期范围选择器的边界处理。保存视图时保留可理解的条件含义，比只存下一串不透明日期更便于讨论。

修改后，先让用户看出还没有保存

创建视图可以从筛选结果页发起：用户设好“本周”和“未分配”，点击保存视图，填写名称并选择个人或团队范围。保存后，页面显示当前视图名称及条件，不能只弹出一次成功提示就没有后续入口。

之后增加“高优先级”时，先把页面标为已修改。用户可以保存修改、另存为新视图，或放弃这次调整回到原条件。名字相同并不能证明是同一份视图；同名时可提示所属范围或要求更明确的名称，避免误覆盖。

在Pixso画布中放出三张工单页面：原来的“本周未分配”、加上“高优先级”后的未保存状态，以及另存成功的“本周高优先级未分配”。三张页面使用同一组条件标签，只有本次改变的条件与视图名称不同。

如果用户离开页面，未保存的临时筛选是否保留也要约定。频繁切换视图的工作场景，可以允许临时查看而不要求每次保存；一旦提供“放弃修改”，它就应该恢复原条件，而不是把用户带回毫不相关的默认列表。

共享条件，不等于共享所有工单

本例个人视图只由本人维护；团队视图有明确维护者，其他人可以使用和另存为个人版本。没有修改权限的人看到的是“另存为”，不应先允许编辑所有条件，最后才提示不能保存。

共享只是让别人使用相同的筛选定义，数据结果仍受各自的业务权限约束。客服A有权查看的工单与客服B不同，不能通过保存或分享视图绕过限制。如果一个视图只对某处理组开放，应在名称附近说明适用范围。

团队视图被维护者修改后，正在使用它的人如何得到新版本，需要一起设计。可以在再次打开时使用最新定义，并说明条件已更新；不宜在用户正准备批量处理时悄悄改动结果集合。多人同时维护的场景，还要提供冲突说明，不能把后来一次提交无声地覆盖前一次。

条件失效时，把问题留在原位置

假设视图里保存了“处理组：售后二组”，后来该组被删除。不能直接丢掉这个条件后展示全量工单，否则结果扩大了，用户却仍以为处在原范围。可以保留失效条件标签，说明该处理组已不可用，让有权限的人选择新的组、移除条件或另存。

当前条件有效但没有匹配记录，是“没有结果”；条件本身不可执行，是“视图需要修复”。两者的文案和动作不同。删除一个视图也只应移除查询入口，不应删除它曾显示的业务记录。

在评审中分别走通这三条路径：正常打开并得到最新记录、临时增加条件后放弃、共享条件失效后修复。需要先完善搜索框与过滤器本身的反馈，可阅读搜索、筛选与结果恢复的设计方法，再把稳定的查询保存成可复用入口。