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