建议把服务器端的用户、角色、权限、组织等基础能力做成内建页面

不知道官方出于什么考虑，将这套逻辑放在服务器端，而提供一套服务端接口。

用户、角色、权限、组织是每套系统必备的功能，但一直放在服务器端，使用时其实很不方便，很多时候还是需要重新在前端实现这套逻辑。
建议官方把这些基础能力直接做成内建页面。

主要是官方没有系统库表对用户创建行为管理，用户创建页面完全可以将页面基础信息写入系统表。对于权限无非就是一个页面有无进入的权限，更多的是页面控件的权限，而常用控件权限无非是页面主记录的增删改查导印这些，其实都可以固定的，在难缠的客户也很少在权限上个性化。而权限这一块目前活字格模式并不工业化，对于新手设计权限也不友好。的确官方应该将权限大改，适应快速开发需求，比如记录的本人，本人的部门等这种和用户属性挂钩可以具备的权限，这种由用户来设计是不科学的，并不是每个设计者都能深刻理解权限底层逻辑的。参照某哲那种权限系统来一套真那么难吗？组织，角色，组织角色，用户，权限页面进入，记录的增删改查导印，高级自定义权限由用户去设计，常用的内置。权限这块老生常谈了。

官方也没办法,页面授权不好分配

已经记录需求啦~各位大佬~

收到~

可以看一下公开课，关于用户管理、组织管理在前端实现：
https://gcdn.grapecity.com.cn/course-408.html

jiangcj369 发表于 2023-6-6 10:50
主要是官方没有系统库表对用户创建行为管理，用户创建页面完全可以将页面基础信息写入系统表。对于权限无非 ...

非常同意，不是所有用户都懂得用户管理的复杂逻辑，官方有点不作为，应该像作者【图2】内置给所有用户，不然很多菜鸟开发者都做成单机版了。

感谢各位老板的反馈，当前可以参考以下demo和公开课：

https://marketplace.grapecity.co ... tabName=Tabs_detail

https://gcdn.grapecity.com.cn/course-425.html

https://gcdn.grapecity.com.cn/course-408.html

WangZhiQing 发表于 2024-8-11 15:09
非常同意，不是所有用户都懂得用户管理的复杂逻辑，官方有点不作为，应该像作者【图2】内置给所有用户， ...

全面了解一下，你会发现权限这一块挺别扭的，页面资源和数据权限分配好以后，是直接写在服务端目录的tables下的json文件中的，而不是放在数据库表中的，不好管理；官方提供的那一套权限做法就是一堆小角色套在大角色里，把大角色分配给人员。实际处理的时候很是复杂，一个页面功能要一大堆小角色，比如采购订单页面，正常需要的权限有：进入该页面的权限，新增记录，修改记录，仅修改个人，仅修改个人和下属，仅修改本部门及下属部门的，删除记录和查询记录也大致会有这些，另外再设计导入，导出，打印权限的时候，你自己想一想这到底需要多少个小角色；这还是一个页面的。
本来系统是可以控制用户创建行为的，只需要内置系统表，页面管理表单用来管理用户设计器端设计的每一张页面的名字，别名，ID，以及一些页面配置信息，这样针对该页面表相对应的进入，新增，修改，删除，查询这几项权限都可以写在内置系统表内，便于前端设计者设计使用，也方便交付客户后由客户自由调整权限。之前官方回复是活字格是自由的，没办法控制，但是我想说的是针对任何系统的增删改查没有什么不同，谁也玩不出花花来，本来应该统一设计成内置的功能，现在全部要由开发者去搞。活字格发展到10了，代码写了那么多，权限这一块已经死死钉在底层上了，即使他们意识到也难以去改变了。
--最好的解决方案就是只使用官方底层的用户登录逻辑，所有页面全部只分配登录用户角色，然后其他一切表自己设计，特别是设计一张系统权限表，页面设计的时候把新增，修改，删除，导入导出等这一类的按钮都对应到你的系统权限表内；当用户登录后，点击某个按钮时，先从系统权限表中取数据判断有没有操作这个按钮的权限，如果没有则提示没有权限，如果有权限则进行下一步的业务逻辑。
举例：比如你设计了一张采购订单页面，页面上有新增，修改，删除，查询等按钮，那么你需要在你的系统权限表内新增一条记录：采购订单， 用户ID或者角色ID，新增列(True or False),其他几列也这样。
当用户A登录后，点击新增按钮，触发系统权限请求的服务端命令，把用户A和请求的ID发送到服务端，去系统权限表内查找匹配，当查询到用户A在采购订单的新增列下是False时，则弹窗提示，没有新增权限；为True时，则进行新增的操作；这种做法不需要针对每个页面设计一大堆角色，只需要分配给登录用户角色即可，另外维护好自己设计的系统权限表，再用好权限请求命令，我感觉比那一堆小角色套大角色做法更好。