比如在一个汽车维修的系统,维修公司员工会上传每个环节的维修内容和图片,用户可以看到员工的姓名、岗位(角色)、维修内容等。假如后续这个员工离职后,这个维修内容该怎么处理呢?
直接在公司员工表把这个员工删除,那员工写的这些维修内容该如何处理?
1.1 员工关联的维修内容也一起删除。(这个肯定不行,这些内容应该属于是公司的资产,用户也应该一直能看到)
1.2 维修内容表取消员工表 id 外键,删除时把维修内容表里的员工 id 设为 null
,用户看到的维修内容员工显示为已离职。(个人觉得这个也不合理)
在公司员工表里加一个 deleted_at
字段,也就是软删除,其他任何数据都不作处理。假如后续这个员工再入职这个公司时,那这个员工之前的数据要不要恢复?
2.1 直接在公司员工表再新建一条新数据,也就是一个新账户,不恢复原来的数据。
2.2 把 deleted_at
设置为 null
,也就是恢复该员工原来的所有数据。(个人倾向于这个方案)
1
AoEiuV020JP 2023-09-22 12:06:59 +08:00
我们公司的禅道系统里,离职了的员工名字会改成拼音首字母,不知道出于什么考虑,
|
2
wxw752 2023-09-22 12:17:56 +08:00
号冻结了就可以了 其他的不动
|
3
Inzufu 2023-09-22 12:24:40 +08:00 via Android 3
如果是要考虑合规性,特别是欧盟的合规性,软删除肯定是不行,如果被员工知道了会被告。
还有根据 GDPR 的数据最小化原则,员工的姓名需要被匿名化或删除,就是以一个可识别字段代替员工的真实姓名。 我建议就是把离职员工名字里面的几个字拿*号抹掉,或者直接显示已离职,因为员工都已经离职了,即使让客户知道名字也没有用了。 |
4
bk201 2023-09-22 12:25:36 +08:00
员工的一个状态,标记一下不行吗?
|
5
512357301 2023-09-22 12:28:58 +08:00 via Android 1
我用 2.1
新入职就是新人了,为什么要重新启用?给个新 ID 就行了 |
6
Daniel17 2023-09-22 12:30:27 +08:00
注销账号之后再注册以前的数据还会存在?
|
7
huntagain2008 2023-09-22 12:38:17 +08:00
记得酒店的饭卡充值系统是将离职的员工姓名改为 old_姓名 ,都是人力资源的不懂电脑的人独立操作的,数据库发现带有 a-zA-Z 字母开头的就 pass ,不做充值的操作。
|
8
yinmin 2023-09-22 12:41:29 +08:00
1. 关于删除:如果有关联子信息,不允许删除
2. 加一个状态“在职/离职” 3. 关于再入职:如果 HR 要保留原工号,就把状态从离职改成在职即可;如果换工号做新员工入职,就再起一条新员工的记录 |
9
jerrry OP @AoEiuV020JP 也就是软删除?
|
11
coderluan 2023-09-22 13:04:29 +08:00 2
最开始就应该有个状态表示在职和离职,然后离职的情况下不产生新的数据,个人信息隐藏。
|
12
kiml 2023-09-22 13:05:17 +08:00 via Android
离职了把所有关联数据转移为默认虚拟员工不就好了,然后写个转移 log 。至于员工数据去留,看业务需求啦
|
13
vx007 2023-09-22 13:14:39 +08:00 via Android
我离职后,我的生辰八字,感情状态,岗位信息等还在人事系统公开可查
|
14
xdao0324 2023-09-22 13:15:54 +08:00
做标记,例如原告在系统里面 显示 为张三,离职后加个字段 张三[已离职]
|
15
Inzufu 2023-09-22 13:17:49 +08:00 via Android 3
@jerrry 是这样,不过还有一些细节问题:
首先任何国家的隐私法都允许保留员工的纳税记录、合同等法律文件以供今后出现法律纠纷时调用,不过这是公司其他部门该考虑到问题,和你关系不大。 其次,用户的数据在法律上分为内容数据和非内容数据,前者为用户产生的例如文件、聊天、工单回复等内容,而非内容数据指用户的个人信息、身份信息、登录密码等数据;一般来讲数据匿名化的重心在非内容数据上。 最后,数据匿名化并不是完全把员工的信息全部抹去,因为上面提到了法律允许保留一些法律文件,但如果采用真匿名处理员工数据,那么这些法律文件则不能和员工本身相关联,所以一般使用“假名化”代替匿名化处理数据,假名化也是 gdpr 所允许的。 最后的最后,如果你公司没有国外(或港澳台)员工,那么不用太多考虑这些问题,因为国内基本不管。 |
16
tool2d 2023-09-22 13:21:36 +08:00
|
17
Vindroid 2023-09-22 13:26:01 +08:00
软删除就好了,记录留着,谁知道什么时候会有需要调出来看下,也不占多少空间
|
18
nzynzynzy 2023-09-22 14:57:29 +08:00
用员工号代替姓名,加一个状态:有效 = true/false ,再回来就继续修,或者启用一个新员工号就好了。
维修内容显示员工应该是“E0035 王强”,而不是“王强”,不然等你有俩王强时候就热闹了 |
19
SenLief 2023-09-22 14:58:53 +08:00
可以借鉴一下企业微信的做法,该员工离职后,原有工作内容交接给下一位继任者。维修内容是属于公司和客户的,不属于员工的。
对于员工内部数据库应该标记离职,对应调取的权限应升级,对外保留账号不就好了。 |
20
masterclock 2023-09-22 15:05:07 +08:00
“软删除” (置 deleted_at )并不等于 “修改员工状态为离职”
共用一个字段很可能在一些情况下引发问题 |
21
blackkkk 2023-09-22 15:22:13 +08:00
用户一般都是软删,至于你说的那种情况更多是用户的状态。用户一般会有状态字段也有删除字段,不冲突。
|
22
openliucongbx 2023-09-22 16:04:11 +08:00
|
23
openbsd 2023-09-22 18:37:33 +08:00
汽车维修这种可能涉及安全的,操作人员信息也要清除吗 ?
参考施工单位,项目竣工 10 年后事故,还要追责承建和施工人员 |
25
jerrry OP @masterclock 谢谢提醒,离职用 resigned_at 可能更合适一下
|
26
julyclyde 2023-09-23 18:23:26 +08:00
给你们讲个笑话:
当年美团某系统,资产的外键是人员的主键,离职即删人 然后资产也被删了 |