Docusignapi 为嵌入签名创建收件人视图时，收件人未知\u信封\u

在创建的许多信封中，有一个信封无法创建用于嵌入签名的收件人视图URL。在下面的示例测试中，两个信封ID中的一个失败

    DocuSign.eSign.Client.ApiException : Error calling CreateRecipientView: {
       "errorCode": "UNKNOWN_ENVELOPE_RECIPIENT",
       "message": "The recipient you have identified is not a valid recipient of the specified 
     envelope."
      }

而另一个envevlope ID通过。注意，我们创建的信封将ClientUserId和电子邮件设置为相同的值。我们使用的技术是将用户名设置为GetRecipientsList指定的值（并且总是这样），但它仍然失败，因此这与已经回答的类似问题不同

    [Theory]
    [InlineData("redacted")]
    [InlineData("redacted")]
    public async Task ShouldCreateRecipientView(string envelopeId)
    {

        var accountId = await new DocuSignCredentials().GetDocuSignAccountIdAsync();

        var envelopesApi = new EnvelopesApi();
        var recipientList = await envelopesApi.ListRecipientsAsync(accountId, envelopeId);
        Assert.Single(recipientList.Signers);
        var signer = recipientList.Signers.First();

        var viewOptions = new RecipientViewRequest()
        {
            ReturnUrl = "http://localhost/return",
            ClientUserId = signer.Email,
            AuthenticationMethod = "password", 
            UserName = signer.Name,
            Email = signer.Email,
        };

        var viewUrl = await envelopesApi.CreateRecipientViewAsync(accountId, envelopeId, viewOptions);

    }

编辑：如果我们像下面这样设置viewOptions，它仍然会以同样的方式失败。控制信封ID继续通过

        var viewOptions = new RecipientViewRequest()
        {
            ReturnUrl = "http://localhost/return",
            AuthenticationMethod = "password", 


            ClientUserId = signer.ClientUserId,
            Email = signer.Email,
            UserId = signer.UserId,
            RecipientId = signer.RecipientId
        };

---

能否将RecipientId添加到RecipientViewRequest对象？并确保它与创建信封时使用的内容相匹配？这将有助于识别系统正在寻找的收件人。

这是带有签名采用的Docusign错误

为某个收件人创建一个信封

收件人在字段上签名，采用新的签名和全名，并执行“稍后完成”

使用与第一个信封完全相同的寻址参数为同一收件人创建第二个信封

收件人在第二个信封上签名，这是关键部分，采用第二个签名（虽然他们仍然可以看到第一个签名），并使用不同的全名，然后再次执行“稍后完成”

收件人试图打开第一个信封；嵌入式签名创建收件人视图现在将以“未知收件人”失败，因为信封中的收件人信息不反映附加到收件人用户id的最新全名

如果嵌入的签名代码能够计算出采用的最新全名，并在创建收件人视图时将其用作UserName参数，那么它将起作用。但由于授权限制，很难获得最新的全名

---

我们正在使用的解决方法是，在创建信封时，通过使用ClientUserId的随机字符串，强制每个信封使用新的Docusign用户id。这并不完全令人满意，因为用户的签名体验不再是最佳的——他们必须接受每个信封上的“电子签名和记录”条款，而且他们将无法维护签名列表。而且这对所有破损的信封和我们已经创建的信封都没有帮助。

正如kayjeta所指出的，存在一个边缘案例，涉及多个飞行中的信封和同一个俘虏签名人的多个签名。最终结果是一个信封，其中getEnveloperRecipients调用返回的签名者名称与信封中的名称不匹配，从而导致对收件人令牌的请求失败

要解决此问题，应用程序可以：

1） 使用创建信封时定义的原始名称发出收件人令牌请求

2） 获取getEnveloperRecipients调用的结果，并将其插入到对信封进行“重新同步”的调用中，然后将所有内容重新对齐

---

已针对此行为提交产品问题。内部跟踪为EC-1965。

如果受约束收件人尚未完成签名，原始收件人信息将继续有效。如果他们已完成签名，并且您希望在随后的某个时间点将其返回信封，则您需要获取现在更新的名称，并将其用于收件人视图API，或者您可以获取用户ID，并将其用于“收件人视图”的所有后续使用，以代替名称和电子邮件。我建议采用后一种方法，因为签名者对名称的更改不会影响分配的“userId”值

我们在创建信封时不设置RecipientId。让我们困惑的是，这个错误只发生在一个信封id上，而不是其他任何信封id上。这就像API在信封中对收件人撒谎一样。我们已经做了一些工作，并将其范围缩小到ClientUserid——如果我们传入UserId和ClientUserid对，那么“控制”信封ID仍然会通过，但测试中的信封ID会失败。如果我们只传入UserId，那么两个信封id都会传入。（但是，生成的嵌入式签名体验是只读的。）每个收件人都有一个与之关联的recipientID。如果您不知道它是什么，您可以通过拨打GET电话来找到它，以获取收件人的所有信息。您必须传递clientUserId才能嵌入签名体验是的，我们知道嵌入签名体验需要clientUserId；我们正试图分离出API不喜欢的内容——它显然无法匹配这个特定有问题的enveopeId的ClientUserId。另外，请参考上面的编辑——以上次编辑的方式构造视图请求选项应该是防弹的。是的，现在看到了，您正在传递RecipientId。您确定收件人ID、用户名和电子邮件与信封上的内容相同吗？