请提前注意：权限与文档访问有关，权限与函数访问有关。具体的执行权限仅适用于模块访问，不适用于文档访问。

有很多方法来组织安全性，但是基础知识通常非常相似。我将为您提供一种模式，我个人认为这是一种良好的做法，并且可能被证明是进一步扩展的良好起点。

从4个角色开始，这些角色本身没有属性。在名称中输入“ read”，“ insert”，“ update”和“ node-update”。

使用名称中的“ defaults”创建第五个角色，并为其赋予上述四个角色的默认权限，其中功能与角色名称匹配（对于读取角色等为“ read”，等等）。

然后为抽象概念（如读者，作家和维护者）创建更高级别的角色。 Reader仅继承读取角色，writer继承读取器，插入，更新和默认值。维护者继承作家。删除是一种特殊的更新，无法区分。节点更新是更新的子集。我还没有遇到想要允许节点更新而不是完整更新的用例。

此处执行权限没有意义，因为这仅适用于模块，不适用于文档。执行特权用于允许使用特定功能（例如sem：sparql，xdmp：http-get等）。将它们适当地应用于读者和作家角色。

避免对上述任何角色应用更危险的执行特权，例如xdmp：spawn和xdmp：eval。如果您有需要，请创建一个用于Amps的角色（可以在名称中添加“ amps”），并确保仅将该角色用于Amps，并且切勿将其分配给角色或用户

最后但并非最不重要的一点是，您经常在同一数据库中拥有多个不同的数据集，并且您可能希望独立控制文档对它们的访问。在这种情况下，考虑考虑使用隔室安全性，而不是为每个数据集创建一组不同的角色。

HTH！