已经做到这种程度了，为什么不是把需要的权限点写在数据库里面？
写在数据库里，可控制程度更好，而且也不用考虑安全性的问题。
管理端只要设置用户的角色，然后用查询或者视图来获得这个用户的权限，不是更好么？
用角色的这个方式，如果权限点很多的以后，会让设置工作很困难的，因为受到界面的限制，展示的方式不好，当
设置的角色足够多以后，就会比较乱了。
我们也在做同样的工作，做法就是把要控制的点作为一个资源，比如页面，菜单，以及页面中的某一个单元格。
把这些资源建个数据表，放在数据库里面。
因为这些点都是基于页面的，所以可以用树状目录来进行设置。
安全性上面，这个权限设置作业也只是一般的权限，可以不用让管理接触后台管理端。
目前不方便提供工程文件，只能发个图说明一下：
有个这个资源表，剩下的就好办了，
把用户角色绑定这些资源。
然后可以写一段标准调用代码，在页面加载的时候，得到登录用户，当前页面的权限表，
同时自动控制这个页面上控制点的可见，启用，只读，影响等属性。
而不需要每个控件再写一堆代码来判断。只要把控件命名好，和资源表里的ID一致就可以了。
期待新版能在权限设置，必填项检查（目前的方式体验很差），有效性检查等方面大幅度改进一下。
新版本表格的验证确实已经搞定了:$ dystar001 发表于 2019-9-3 22:53
和楼主交流一下：
已经做到这种程度了，为什么不是把需要的权限点写在数据库里面？
我选择用这种方法做的原有是，为了尽可能兼容活字格本身的权限机制（主要是懒不想额外写代码），让页面权限和菜单控件的权限 可以直接跟活字格原来的角色匹配起来。
其实如果有必要还可以跟数据库权限也匹配起来。
不用另起一套底层的权限规则，尽量用活字格本身的底层权限来实现控制，活字格原生的权限控制相对更底层不容易被绕过更安全一些。
整个思路其实并不是要放弃活字格本身的权限控制结构，而是为了发布后更方便重新分配管理权限。尽量减少再次通过设计器修改权限关联关系，重新发布的工作。
仔细研究了你的方法后觉得，你的做法也很不错。不过看完你的方案后发现需要再代码开发过程中就规划好，相关的页面名称，相关的按钮名称等。当一个工程需要多个人一起开发时多出很多协同规范之类的事情。我可能比较懒，不想这样规划，完全是将不同的模块分开来让不同的人开发，开发阶段开发人员完全不考虑权限控制的问题只考虑功能的实现。开发完成后合并工程，然后直接统一做一次页面，按钮，菜单，数据库等需要控制权限的地方简单粗暴的，通过简单分类后直接挂角色上去控制权限。
所以自省一下自己，我是不是太懒了。感谢你的分享 我要是说活字格新版，可以在前段直接修改也买权限和UI权限了，你是不是要砍死我:L Simon.hu 发表于 2019-9-4 18:41
我要是说活字格新版，可以在前段直接修改也买权限和UI权限了，你是不是要砍死我
放心我不砍死你:lol
其实折腾这么一大堆目的还是为了解决问题，官方能直接实现满足需求我是大大支持的。经历了4.0-5.0的版本更替，新增的功能极大的提高开发效率。
只要活字格一直进步，收益的是我们这些使用者，特别是每个版本更新都能看到我迫切需要的功能的时候晚上睡觉都会安稳一点。可以少加几天班，少掉几根头发。
正在期待5.1新功能，现在每天都来关注一下，每天都有惊喜。 本周4或者下周一，我们发布一个内测版，大家可以试试
页:
1
[2]