所谓权限控制，无非就是限制系统中的部分用户增删改查表或者字段的过程。
	
	在新建一个table时，我们会看到一个 ‘Create access controls’和’User role‘ ，如下图：
	![](https://s1.51cto.com/images/blog/201901/09/ee4a41d5a51dba5700e54a915878916e.png?x-oss-process=image/watermark,size_16,text_QDUxQ1RP5Y2a5a6i,color_FFFFFF,t_30,g_se,x_10,y_10,shadow_20,type_ZmFuZ3poZW5naGVpdGk=)
	
	勾选了’Create access controls‘后，需要新建或是选择一个已有的角色。
	引用官方文档的介绍：
	”Create access controls：Select the check box and then complete the User role field to create basic security rules for the table“
	”User role：	Enter a new name or select an existing user role that is required to access this table. This option is available only when the Create access controls check box is selected.“
	很好理解，这个带有这个 role 的 user 才可以 控制该表。
	
	每一个table ，都对应的可以设置自身的ACL
	ACL的Role required: security_admin
	具体的设置方法与说明请参考官方文档：
	https://docs.servicenow.com/bundle/kingston-platform-administration/page/administer/contextual-security/concept/acl-rule-types.html
	
	ok,下面说下遇到的问题的总结。
	在实例开发中，如果没有role的 user不能查看相关数据，而admin或其他role的user可以查看到，那么我们就肯定可以断定，是table或者table里的field设置了ACL。
	Example 1：
	在某些list中，普通user看不到部分record，说明该user不满足这部分record的ACL里面的role设置或者condition设置。
	Example 2：
	在form中，普通user看不到部分Fields，同上，该user不满足field相应的ACL。
	Example 3：
	有时候，user明明可以看到field，却查看不到该field的值。这种情况，一般是因为该field是Reference类型，需要从其他table查询数据，所以，对应的是user不满足Reference的table的相应的ACL.
	分享一个案例：
	Portal里的table list 里对于普通user始终无法显示A field 的值。但是后台系统的table list 却能显示这个field的值，
	又因为没有对A field设置特殊的ACL,所以理论上应该所有人都可以read，但事实在portal的widget查询数据后，怎么都显示不出来。最后发现A field是Reference类型，于是我去查看了reference对应的table的ACL，果然是普通user不满足这个ACL。
	
	
	********************************Created by Aaron Wang*********欢迎转载留言讨论*************************