一种介于待办和通知的需求有没有好的思路?

2022-06-16 10:32:04 +08:00
 shyrock

公司的 erp 软件,每个不同的角色有自己的不同的待办事项。 根据其人所属项目、所属部门、所属角色需要推送不同的待办通知给他。

目前的实现有两个思路,一是点击后根据这个人的各项属性查询数据,并过滤出需要他处理的事项。这个的问题是性能太低,点了之后要查一分钟才能看到所有待办。 二是后台监控内容变更,当满足某人的条件时,推送一条消息给他。客户端只需要列出该人的所有待办消息即可,性能很高。缺点是在其他终端处理了事项时没有办法消除所有终端的通知,需要人工点击完成待办。

这两种方案似乎是优劣互补的,但是我没有好得思路能结合到一起。 不知各位大佬有没有更好的思路?

3555 次点击
所在节点    程序员
55 条回复
Saxton
2022-06-16 10:54:29 +08:00
第一个方案有问,为什么要根据这个人各项属性查询数据?难道生成的这条待办没有归属人吗,还是说大家都可以处理掉这个待办
第二个方案也有问,"缺点是在其他终端处理了事项时没有办法消除所有终端的通知" , 这个不是很正常吗, 通知这个东西一旦下发就很难做撤回的操作了。

待办事项的推送这块我也做过,不过场景没楼主这么复杂,都是一定条件后会触发一条系统内的消息和系统外的消息推送,条件的监控是监听数据库的 binlog 日志来做的,完全解耦并独立于系统外的,我的设计方式是设计好一套规则,如果监听到的数据行为符合这个规则就生成一条待办并完成推送,规则这块我设计了一个规则模板引擎,让运营在后台自己设置。
Saxton
2022-06-16 10:58:47 +08:00
但我这个解析 binlog 的方式也有一定局限,在操作上有一定受限,毕竟是完全解耦独立的, 无法参与到业务逻辑中, 就看你需求了。
shyrock
2022-06-16 10:59:11 +08:00
@Saxton #1 有的待办有明确归属人,有的待办可以有多个人可以处理。
shyrock
2022-06-16 10:59:39 +08:00
@Saxton #2 似乎你的方法也只能手动点击完成待办,对吧?
gainsurier
2022-06-16 10:59:56 +08:00
告警
shyrock
2022-06-16 11:00:18 +08:00
@gainsurier #5 ??
Saxton
2022-06-16 11:03:45 +08:00
手动点击完成待办? 我们没有这个需求, 所有待办自动完成的, 触发规则就完成他, 比如 小明今天新增了一个合同信息,但合同还没签约, 这个时候就会新增一条合同签约待办给小明, 但如果当合同的状态变更为签约, 这个待办自动完成。 我设计的规则模板可以指定待办触发条件和完成条件
Saxton
2022-06-16 11:05:27 +08:00
shyrock
2022-06-16 11:06:08 +08:00
@Saxton #7 明白了,就是跟触发通知一样的逻辑,后台监控发现完成了就消除通知?
Saxton
2022-06-16 11:08:01 +08:00
@shyrock 是的 不能说消除通知吧 ,通知这个东西一旦下发下去, 什么状态就什么状态, 而且通知一旦下发下去,你去手动消除他反而更不符合业务需求,用户明明收到他通知了,但被你删了,等到他看却发现没有,这个行为就很奇怪了。
待办会被变更为已完成。
shyrock
2022-06-16 11:10:05 +08:00
@Saxton #10 意思是看通知,待办数量是 1 ,点进去看待办数量是 0 ?(因为已经后台监控修改了待办状态)
nothingistrue
2022-06-16 11:12:04 +08:00
为啥,不两个都用。

第一个思路不用于通知,而是用于个人收到通知后(或者随时)的主动查询。这是类似于“我的……”的功能,有没有通知都要做。

第二个思路,去掉“完成待办”操作,增加“已读”操作,如果有闲工夫,还可以增加跨终端消息已读状态同步功能,再有闲功夫,还可以增加“之前你的某某任务已被他人处理”提醒消息。

通知 /推送的主体是系统,待办任务的主体是个人,这俩是两码事,要分开处理,合在一起就会引起混乱。在细分一点,通知消息的生成跟读取也要分开,前者主体是系统,后者主体是个人。
Saxton
2022-06-16 11:13:03 +08:00
@shyrock 像你所说的,一条待办可以很多人处理,那就肯定会下发通知给多个人, 其中一个人完成其他人的通知还存在,这个行为很正常,你想想,一个人收到一条待办消息,暂时没空处理,另外一个人正好有空给他处理了,但第一个人要处理的时候发现通知怎么没了, 就很奇怪了,正常的逻辑是第一个人想要处理点通知进去发现已经被处理了就不处理了,这个逻辑很正常,但有些产品设计时会考虑到用户对通知的反感度, 太多的消息反而都不用处理就会引起用户的不满,就看产品怎么说了。
nothingistrue
2022-06-16 11:16:21 +08:00
通过在通知消息中附加待办的处理入口,让用户可以从消息直接导航到相关任务,这样可以提高用户的效率。但是这是““我的……””功能的辅助,不是替代——就是别用“我的未读消息”来代替“我的……”
Saxton
2022-06-16 11:17:51 +08:00
@shyrock 其实不用在这纠结这个 01 问题,这个是产品该纠结的问题,产品如果需要那肯定就是需要,除非你就是产品。
shyrock
2022-06-16 11:18:19 +08:00
@nothingistrue #12 问题在于主动查询太慢了,有些岗位十多二十个待办种类,每一个都即时查询很花时间。
Saxton
2022-06-16 11:19:35 +08:00
@shyrock 主动查询太慢,我有点不是很理解,待办这种东西不应该是生成一条记录然后给到归属用户嘛,就算归属多人一样可以再字段上体现,查的时候只需查待办表就行了。
shyrock
2022-06-16 11:19:59 +08:00
@nothingistrue #14 确实也是从消息导航到处理界面。重点还是第一个问题,每次即时查询待办太慢,所以才想是否可以用通知代替即时查询。。。
shyrock
2022-06-16 11:25:23 +08:00
@Saxton #17 你说的这个方法就不是点击时主动查询了,实际上是后台查出来后更新到一个待办表,问题在于待办表什么时候插入记录?这里有两个选择:一是定时轮询,好处是可以外挂逻辑,不用侵入到业务代码。缺点是要为每个人的每种待办查询,速度是个问题 i ;
二是在业务逻辑中判断并插入到待办,缺点是侵入了业务代码,要改的地方很多很分散。。。
shyrock
2022-06-16 11:26:00 +08:00
@Saxton #15 也算产品吧。

这是一个专为移动设备优化的页面(即为了让你能够在 Google 搜索结果里秒开这个页面),如果你希望参与 V2EX 社区的讨论,你可以继续到 V2EX 上打开本讨论主题的完整版本。

https://www.v2ex.com/t/859954

V2EX 是创意工作者们的社区,是一个分享自己正在做的有趣事物、交流想法,可以遇见新朋友甚至新机会的地方。

V2EX is a community of developers, designers and creative people.

© 2021 V2EX