2、文档权限

作者域:
“作者”域与数据库存取控制列表中的“作者”存取级别协同工作。如果在存取控制列表中指定某个用户具有“作者”存取级别，那么他可以阅读数据库中的文档，但是不能进行编辑即使是他自己的文档。将用户列入“作者”域可以使他们能编辑自己所创建的文档，从而扩展了他们的存取权限。

“作者”域中的项目不能超越数据库的存取控制列表，而只能细化它。在数据库中被指定为“不能存取者”的用户，即使被列入“作者”域也绝不能编辑文档。已经具有数据库“编辑者”（或更高）存取级别的用户不受“作者”域的影响，“作者”域只影响在数据库中具有“作者”存取级别的用户。

读者域

如果希望限定对由某个表单所创建的特定文档的存取，则在表单中添加一个“读者”域。“读者”域清楚地列出了可以阅读由此表单所创建的文档的用户。例如：如果限制某个员工的人事档案只有“人力资源”部门的成员、员工本人以及员工的经理可以存取，则可将这些人员列在“读者”域中。对文档不具有“读者”权限的用户则不能在视图中查看文档。如果表单中有存取列表，那么“读者”域中的姓名将被添加到表单的存取列表中，否则，由“读者”域控制对由此表单所创建的文档的存取。

“读者”域中的输入项不能给用户比数据库的存取控制列表 (ACL) 中指定的权限更高的存取权限，而只能进一步限制存取权限。在数据库中被指定为“不能存取者”的用户，即使被列入“读者”域也不能读取该数据库中的文档。另一方面，在存取控制列表中具有“编辑者”（或更高）存取级别的用户，若未列入“读者”域中，也不能读文档。

3、  其他权限

（1）       服务器权限，这个我不是很懂，比如说服务器ID

（2）       角色。这个应该归到数据库的ACL权限中。
角色是对存取权限进行细化的重要手段。从某种意义上来说，角色可以理解为仅在本数据库内部起作用的群组。假设某个文档的读者域中只包含一个角色的名称，那么，不具有此角色的用户，即使拥有管理者权限也无法看到此文档。
使用角色对数据库的设计者和管理者都很方便。对设计者来说，在开发阶段完全不必考虑最终用户的具体名称，也不必把群组的名称固定地写在代码中，只要定义并使用一系列角色即可。特别是对数据库模板的设计者来说，这一点更为方便。对管理者来说，不必为某个应用去修改公用通讯录，增加或删除群组，而只要将用户或群组的名称加入ACL，赋予他们适当的存取级别和角色，就可以让他们正常地使用该应用了。

角色主要只是准对当前数据库有效（个人和群组是公用通讯录中的，全局的，显然角色是权限的针对具体数据库的细化），我们可以定义一些个角色，比如[甲]、[乙]，什么的，然后我们可以将ACL中的个人或群组指定为[甲][乙]角色，然后就可以在数据库设计中使用了，当然我们也可以通过代理将用户或群组加入到指定的角色中，然后你具体要如何限定角色的权限就由开发者自行指定了。比如说指定一个文档的读者域,将[甲]放入，那么具有[甲]角色的群组或个人就具有对该文档的读者权限了。

           这样很灵活，比如说我们指定了一个文档1的读者权限是[甲]角色，那么以后我要使用户A对文档1具有读者权限只要将使A用户具有[甲]角色即可了。

（3）       代理执行权限，谁有权限运行这个代理，比如指定用户，或者是Web用户运行

还有就是是否进行安全控制，还有什么个人代理和共享代理之分的。

(3)          然后貌似表单还有权限的，这个没用过

(4)          自定义权限，这就是你的代码进行控制了