cucme 发表于 2023-6-6 09:02:03

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

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

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

一世长安 发表于 2023-6-9 07:37:10


jiangcj369 发表于 2023-6-6 10:50:44

本帖最后由 jiangcj369 于 2023-6-6 11:42 编辑

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


dlxubo 发表于 2023-6-6 09:03:37

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

David.Zhong 发表于 2023-6-6 16:34:57

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

David.Zhong 发表于 2023-6-9 09:07:39

收到~:lol

Patrick.Zhu 发表于 2024-1-15 15:17:42

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

WangZhiQing 发表于 2024-8-11 15:09:26

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

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

Brian.Zhang 发表于 2024-8-13 12:13:37

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

https://marketplace.grapecity.com.cn/ApplicationDetails?productID=SP2312210001&productDetailID=D2312210007&tabName=Tabs_detail

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

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

jiangcj369 发表于 2024-8-19 16:53:24

本帖最后由 jiangcj369 于 2024-8-19 17:03 编辑

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