这是我目前对按下激活按钮事件的理解：
如果用户具有复制权限，则将内容发送到调度程序。 如果用户没有复制，则运行请求激活工作流。开箱即用，这将执行两个步骤，这两个步骤都发送到管理员组。
如果我将 OOB 激活请求工作流更改为分配给另一个组，则该组会在其 CQ 收件箱中收到消息。
我的要求是我有多个网站属于公司内的不同部门，这意味着每个网站都有单独的组，用于只能创作内容的用户和可以批准/激活该内容的用户。在一种情况下，职业部分中的内容还需要仅由人力资源团队批准。
如何更改工作流程以实现这些要求？
【问题讨论】：
我可以想到两种方法：
1) 更改 OOB 框工作流程以使用 OR 步骤根据内容路径切换到不同的组。在处理页面和资产的页面以及职业示例等特殊条件时，这可能会变得非常复杂。
2) 创建一个运行 Java 代码的自定义步骤，该代码使用 AccessControlManager 类查找节点上的复制权限，如果没有，则向上遍历树，直到找到具有权限的节点。
【讨论】：
对于类似的问题，我选择了选项 1)。
如果您主要关心的是 OR 拆分中有太多分支，那么也许有机会将工作流的决策分解为多个步骤，而不是在一个决策点上分支到许多不同的路径。
例如，您可能首先按负载所在的站点进行拆分，然后根据用户类型或站点的部分再次拆分。所以，类似：
网站 1
- 第 1 节
- 角色 1
- 角色 2
- 第 2 节
站点 2
... 以此类推，其中每一级缩进代表一个单独的 OR 拆分。
如果您使用容器步骤在每个决策点触发子工作流程，这可能有助于使您的工作流程更有条理。
因为我不喜欢更改 OOB 激活请求工作流程的想法，所以我通过将第一步设置为进行通用检查的 OR 拆分来最小化这种情况 - 基本上：
Pseudo-code:
if (we're in one of the sites that's subject to my custom workflows) {
Container step that points to my main custom workflow;
} else {
Continue with the default Request for Activation workflow steps;
}
这样，您可以对 OOB 工作流程进行最少的更改，并且如果您在同一实例上设置新站点并且不希望它受制于您的自定义工作流程，则可以自行运行默认工作流程。
【讨论】：
我们在每个页面中创建了一个自定义属性，“页面所有者”，它实际上是一个指向组的指针（我希望我们从一开始就让它可以通过树继承）。然后自定义工作流程，以便页面所有者组在其收件箱中收到此内容以供批准。
【讨论】：