通过

为消息修复和新提交创建部门和角色

  • 项目

消息修复和新提交涉及以下四种不同的操作：

  • 修复验证失败的消息

  • 验证修复 (包括重新生成密钥)

  • 批准维修

  • 创建新邮件

    若要执行其中一个操作，用户必须承担与该操作关联的角色。 该角色还必须是处理部门的一部分， (如下) 所述。 若要在工作流中执行阶段后提交消息，用户必须使用与用户关联的有效证书对消息进行签名。

创建部门和角色

请参阅配置文件 Web 客户端文档。

角色使用规则

A4SWIFT用户、角色和部门必须符合以下规则：

  • 修复的消息的完整工作流是修复、验证，然后批准消息。 创建的消息的完整工作流是创建、修复、验证，然后批准消息。 验证和审批步骤是可选的。

  • 部门的工作流必须以创建角色或修复角色开头。 如果工作流包括创建和修复步骤 (创建消息的工作流) ，则创建步骤必须紧接在修复步骤之前。

  • 已创建邮件的工作流必须包含一个且只有一个具有创建功能的角色。

  • 每个工作流必须包含一个且只有一个具有修复功能的角色。

  • A4SWIFT用户可以与多个角色相关联，但单个用户不能在单个工作流中执行多个步骤。 例如，如果用户 A 修复消息，而用户 B 验证消息，则用户 A 和用户 B 都不能批准该消息。

  • 与具有 RekeyVerify 或 Approve 功能的其他角色相比，没有检查具有 RekeyVerify 或 Approve 功能的角色顺序。

  • 如果已修复的消息再次未能通过验证，它将返回到 MRSR 网站文档库中的修复收件箱。 发生这种情况时，以前基于谁已在工作流中执行过角色 (验证和审批者角色的限制) 不再适用。 例如，如果用户 A 修复消息，用户 B 在验证中拒绝该消息，用户 A 再次修复消息，则用户 B 以外的用户可以验证该消息。 如果是这种情况，则用户 B 可以批准该消息。 另一个示例是，如果用户 A 创建了一条消息，用户 B 在验证中拒绝了该消息，而用户 C 修复了该消息，则用户 A 可以验证该消息。

  • 如果消息未通过验证，则创建消息的A4SWIFT用户也可以修复该消息。

  • 只有与工作流关联的部门中的A4SWIFT用户才能执行工作流中的步骤。 当A4SWIFT用户提交消息时，A4SWIFT验证用户是否在部门中具有与消息关联的角色， (通过用户配置文件 (，以防该部门不是配置文件 Web 客户端) 中的默认) 。

  • 管理员可以在部门中为单个A4SWIFT用户提供多个角色。 单个用户可以执行修复、验证、审批或创建，或者执行这些角色的任何子集，但受上述任何一个工作流的限制。

证书

若要在修复、验证、批准或创建后在本地计算机上提交消息，A4SWIFT用户必须使用其证书对邮件进行签名。 有关创建证书的详细信息，请参阅 安装证书。

若要能够通过从远程客户端计算机访问 MRSR 站点来修复、验证、批准或创建消息，用户必须在客户端计算机的证书 - 当前用户/个人/证书存储中添加其证书， (用户不必是管理员即可) 执行此操作。 此外，服务器上的管理员必须将用户的证书 (以及从客户端计算机) 访问服务器的其他用户的证书添加到服务器上 (本地计算机的证书) /其他人员/证书存储。

单个用户可能具有多个分配的角色，在执行其中任何角色时应使用相同的证书。