5、保留、清空这两个欠缺考虑，没有系统化的设计，缺乏人工交互。 （1）实际管理相关复杂，由系统自己识别是手工录入，还是系统同步，缺乏应对管理多样化的实际需求，也缺乏人工交互的特性，缺乏应对管理灵活性能力。对于系统，实际在添加用户界面和修改用户界面，提供选择手工维护和自动同步的选项，实际灵活性更强； （2）保留用户的核心是保证当前系统权限功能的完整性，因此，在保证权限不变的情况下，任何信息均可改变。如以员工编号为唯一关键字，更新用户账号、邮箱等（实际企业中有领导级员工要求使用某账户，而要求员工改账号的情况），因此，功能应是更新、新增，即对于现存用户，以唯一关键字为准进行更新，对于新增用户，增加员工信息，对于离职员工，将账号设为禁用或者删除账户（后者慎用）。可以增加配置项，不存在用户删除或不存在用户禁用等。 （3）对于密码，从安全上密码实际不允许出系统，出系统则意味着密码泄露。因此，密码处理可选项不多，即使用统一单点登录，或者生成随机密码，后续下发给用户邮箱，由用户首次登录自行更改。 因此，保留这一功能，不存在某些情况下组织机构、岗位不变的问题，只要纳入同步范围，就是要保证与HR一致。而角色不一样，角色为本系统中的角色，不应更新。 帆软应高度重视这种系统基本功能，连这都做不对，还指望其它功能？
赞 2 2023-12-27 16:51
你好像没理解，【保留】这个功能作用，这个是为了解决手动添加用户和同步用户冲突的。比如先手动加了几个用户，后来配置同步数据集，数据集里面有这些用户了，【保留】即可以保留其权限和资产
赞 0 2024-04-12 21:04
再次，帆软系统的设计败笔较多 1、设计时未考虑原始数据存在多种异常、同步工具存在异常、通讯异常等异常情况，作为BI软件处理原始数据异常这一基本要求未得到重视，未考虑到整个软件设计过程中。理想的认为原始数据正常，导致同涉过程中大量中断无法继续，实际难以完成同步，不是以能同步多少同步多少，后续再不断修改的思想，给客户造成困扰。 2、强制要求将客户的组织机构表、员工表关联才能导入。这是最反人类的设计，试问帆软自己会将这两张表设计在一张表中吗？实际企业中大量人员是挂在最下级组织，中间组织并不一定有员工。 3、在导入过程中以组织机构名、岗位名称进行唯一性校验。实际企业中大量以组织机构ID为唯一识别字段，组织机构名称校验并无实际太大意义，如有错误，通知客户处理即可，在系统中用不同颜色显示。而岗位名称，实际企业HR系统中，可能有一个基础岗位表，岗位分配到具体部门后，可能还允许具体公司和部门自行调节，这时会出现人员信息中同一岗位ID有多个不同岗位名称或者同一岗位名称有多个不同ID，这是原始系统的问题，但到帆软系统中则变成不可导入的情况。这实际阻断了后面的工作。这实际也是帆软不考虑容错，不考虑先正常使用再逐步修正的处理思想。 4、用户同步时，用用户ID匹配，不符合安全性设计思想。用户ID，主要保证自己系统权限逻辑的正常。如破坏用户ID，可能导致历史权限分配失控。因此，一般不允许外部数据更新该数据。如要更新，一般以员工编号、员工账号、员工身份证号为准进行更新。而当前系统中未提供员工编号字段，很多开发人员直接将员工编号与用户ID匹配，从而可能出现权限分配失控风险。
赞 2 2023-12-27 16:50
数据集的用户id，对应的就是客户其他系统里的唯一不变值，无论你是用户编号还是啥，只要是不变的唯一标志都可以。
赞 0 2024-04-12 21:07
其次，同步用的目标没搞清楚 1、首要目标是，同步过后保证原已经设置权限的用户权限不能改变，一旦清空用户和权限，最终用户配置权限的工作量是海量的，可以视为一次安全事故。 2、用户同步可能存在一异列的异常，包括不限于，原始数据异常、同步功能设计异常、同步时通讯异常等，此时要增加大量的异常处理，但无论如何异常，最基本要保障用户信息同步更新过来，人员信息是全量的，一旦人员信息不全则可能出现无法为新用户授权的异常情况。 3、慎用删除用户功能，因为一旦删除，要想重新配权限，则还会出现海量工作量的情况。因此，在做功能时，一般都应选使用禁用用户功能，即如发现用户不存在时，应先将该用户设为禁用。再通过单独接口，对于删除人员进行单除验证和处理。 4、从企业内部控制要求上，离职人员，必须禁用账户，此功能主要防止离职人员再次访问系统的安全风险事件。 5、在确保人员正确的基础上，进一步同步校验组织机构、岗位等管理特性，在校验时，应确保组织机构上下级关系完整性。而岗位并非必须。同样，考虑异常的情况，在确保现存数据基础上，更新数据，要处理有人员无组织机构、组织机构无上级机构、组织机构名称异常等情况。 以上核心目标均是要保证现存系统的可用性，要保证能同步尽量同步数据，将异常和未同步的情况集中输出给客户，供客户进一步处理。
赞 2 2023-12-27 16:49
你不知道有【软删除】和【熔断】这俩功能吧？ 竞品研究请仔细点奥
赞 0 2024-04-12 21:05
帆软系统做了这么多年了，用户同步的逻辑都没有理清楚。更要命的是实施非常不规范，前端实际工程师没有标准化的处理过程。给用户造成大量困扰。 首先，用户同步要考虑几种场景： 1、用户已经试用系统，或者前期少部分部门使用系统，因此，存在手工添加用户的情况，在后续工作中，正式上线或用户扩大化，以及满足内控上新入职员工加账户，离职员工禁账户或减账户需求，需要自动化同步用户信息； 2、存在一些外部工作人员，需要保留一部分手工添加的用户。 解决这一问题，最佳的做法是在添加用户时，增加一个手工维护用户和系统同步用户的选项（系统同步用户，除能变更选项，其它一切都不能调整）。后续只要将用户更改为同步用户，即需要系统更新信息，如果是手工维护用户则不更新信息。
赞 1 2023-12-27 16:49
大哥们如何临时关闭同步用户的功能呀
赞 0 2023-12-18 14:33
77 评论
5、保留、清空这两个欠缺考虑，没有系统化的设计，缺乏人工交互。
（1）实际管理相关复杂，由系统自己识别是手工录入，还是系统同步，缺乏应对管理多样化的实际需求，也缺乏人工交互的特性，缺乏应对管理灵活性能力。对于系统，实际在添加用户界面和修改用户界面，提供选择手工维护和自动同步的选项，实际灵活性更强；
（2）保留用户的核心是保证当前系统权限功能的完整性，因此，在保证权限不变的情况下，任何信息均可改变。如以员工编号为唯一关键字，更新用户账号、邮箱等（实际企业中有领导级员工要求使用某账户，而要求员工改账号的情况），因此，功能应是更新、新增，即对于现存用户，以唯一关键字为准进行更新，对于新增用户，增加员工信息，对于离职员工，将账号设为禁用或者删除账户（后者慎用）。可以增加配置项，不存在用户删除或不存在用户禁用等。
（3）对于密码，从安全上密码实际不允许出系统，出系统则意味着密码泄露。因此，密码处理可选项不多，即使用统一单点登录，或者生成随机密码，后续下发给用户邮箱，由用户首次登录自行更改。
因此，保留这一功能，不存在某些情况下组织机构、岗位不变的问题，只要纳入同步范围，就是要保证与HR一致。而角色不一样，角色为本系统中的角色，不应更新。
帆软应高度重视这种系统基本功能，连这都做不对，还指望其它功能？
赞 2 2023-12-27 16:51
你好像没理解，【保留】这个功能作用，这个是为了解决手动添加用户和同步用户冲突的。比如先手动加了几个用户，后来配置同步数据集，数据集里面有这些用户了，【保留】即可以保留其权限和资产
赞 0 2024-04-12 21:04
再次，帆软系统的设计败笔较多
1、设计时未考虑原始数据存在多种异常、同步工具存在异常、通讯异常等异常情况，作为BI软件处理原始数据异常这一基本要求未得到重视，未考虑到整个软件设计过程中。理想的认为原始数据正常，导致同涉过程中大量中断无法继续，实际难以完成同步，不是以能同步多少同步多少，后续再不断修改的思想，给客户造成困扰。
2、强制要求将客户的组织机构表、员工表关联才能导入。这是最反人类的设计，试问帆软自己会将这两张表设计在一张表中吗？实际企业中大量人员是挂在最下级组织，中间组织并不一定有员工。
3、在导入过程中以组织机构名、岗位名称进行唯一性校验。实际企业中大量以组织机构ID为唯一识别字段，组织机构名称校验并无实际太大意义，如有错误，通知客户处理即可，在系统中用不同颜色显示。而岗位名称，实际企业HR系统中，可能有一个基础岗位表，岗位分配到具体部门后，可能还允许具体公司和部门自行调节，这时会出现人员信息中同一岗位ID有多个不同岗位名称或者同一岗位名称有多个不同ID，这是原始系统的问题，但到帆软系统中则变成不可导入的情况。这实际阻断了后面的工作。这实际也是帆软不考虑容错，不考虑先正常使用再逐步修正的处理思想。
4、用户同步时，用用户ID匹配，不符合安全性设计思想。用户ID，主要保证自己系统权限逻辑的正常。如破坏用户ID，可能导致历史权限分配失控。因此，一般不允许外部数据更新该数据。如要更新，一般以员工编号、员工账号、员工身份证号为准进行更新。而当前系统中未提供员工编号字段，很多开发人员直接将员工编号与用户ID匹配，从而可能出现权限分配失控风险。
赞 2 2023-12-27 16:50
数据集的用户id，对应的就是客户其他系统里的唯一不变值，无论你是用户编号还是啥，只要是不变的唯一标志都可以。
赞 0 2024-04-12 21:07
其次，同步用的目标没搞清楚
1、首要目标是，同步过后保证原已经设置权限的用户权限不能改变，一旦清空用户和权限，最终用户配置权限的工作量是海量的，可以视为一次安全事故。
2、用户同步可能存在一异列的异常，包括不限于，原始数据异常、同步功能设计异常、同步时通讯异常等，此时要增加大量的异常处理，但无论如何异常，最基本要保障用户信息同步更新过来，人员信息是全量的，一旦人员信息不全则可能出现无法为新用户授权的异常情况。
3、慎用删除用户功能，因为一旦删除，要想重新配权限，则还会出现海量工作量的情况。因此，在做功能时，一般都应选使用禁用用户功能，即如发现用户不存在时，应先将该用户设为禁用。再通过单独接口，对于删除人员进行单除验证和处理。
4、从企业内部控制要求上，离职人员，必须禁用账户，此功能主要防止离职人员再次访问系统的安全风险事件。
5、在确保人员正确的基础上，进一步同步校验组织机构、岗位等管理特性，在校验时，应确保组织机构上下级关系完整性。而岗位并非必须。同样，考虑异常的情况，在确保现存数据基础上，更新数据，要处理有人员无组织机构、组织机构无上级机构、组织机构名称异常等情况。
以上核心目标均是要保证现存系统的可用性，要保证能同步尽量同步数据，将异常和未同步的情况集中输出给客户，供客户进一步处理。
赞 2 2023-12-27 16:49
你不知道有【软删除】和【熔断】这俩功能吧？ 竞品研究请仔细点奥
赞 0 2024-04-12 21:05
帆软系统做了这么多年了，用户同步的逻辑都没有理清楚。更要命的是实施非常不规范，前端实际工程师没有标准化的处理过程。给用户造成大量困扰。
首先，用户同步要考虑几种场景：
1、用户已经试用系统，或者前期少部分部门使用系统，因此，存在手工添加用户的情况，在后续工作中，正式上线或用户扩大化，以及满足内控上新入职员工加账户，离职员工禁账户或减账户需求，需要自动化同步用户信息；
2、存在一些外部工作人员，需要保留一部分手工添加的用户。
解决这一问题，最佳的做法是在添加用户时，增加一个手工维护用户和系统同步用户的选项（系统同步用户，除能变更选项，其它一切都不能调整）。后续只要将用户更改为同步用户，即需要系统更新信息，如果是手工维护用户则不更新信息。
赞 1 2023-12-27 16:49
大哥们如何临时关闭同步用户的功能呀
赞 0 2023-12-18 14:33