We are trying to determine if there is a way to obtain the timestamp of when a Carbon Copy, "Envelope Signed" or "Envelope Completed" email is sent with a json api instead of xml.
We have tested using Docusign connect by selecting the "Envelope Signed" and "Envelope Completed" events under "Send information on these envelope events" in the Docusign console.
Also, when the document is signed, we receive the expected post request to our connect endpoint which includes the following (private info removed) and are wondering if the timestamp in the "Sent" tag means that the carbon copy email was actually sent at that time and therefore we can use it for auditing purposes.
<RecipientStatus>
<Type>CarbonCopy</Type>
<Email>bob#example.com</Email>
<UserName>Bob</UserName>
<RoutingOrder>2</RoutingOrder>
<Sent>2015-07-08T16:14:18.88</Sent>
<DeclineReason xsi:nil="true" />
<Status>Completed</Status>
<RecipientIPAddress />
<CustomFields />
<AccountStatus>Active</AccountStatus>
<RecipientId>dc9521c4-b11d-426c-b409-326b985e823b</RecipientId>
</RecipientStatus>
thanks
PR
Related
I've a custom policy for sign up & sign in and, in the last step, I ask the user to enter the email, where I send a verification code and verify the code (following one of the examples provided by Microsoft). However, I'd like to store, in the "contact info" the email that the person entered.
I tried multiple ways using "PersistedClaims", but it doesn't seem to work.
<PersistedClaims>
<PersistedClaim ClaimTypeReferenceId="signInNames.emailAddress" PartnerClaimType="email"/>
</PersistedClaims>
I got no error when I load the policy, but when I sign up, I still don't see the email in the Contact Info inside the user's profile in Azure AD B2C.
I believe that I'm using the wrong claim, but I couldn't figure out what it the "Contact info -> Email" claim.
Please, could someone tell me which claim and how to store it?
Thank you
Change “email” to “mail”.
Change “signInName.emailAddress” to “signInName” (if this is during sign up)
I have added seal recipients in envelope. I have got electronic seals enabled on the account. I have added only a seal recipient and the Demo Seal guid in the recipientSignatureProvider.
<?xml version="1.0" encoding="UTF-8"?>
<envelopeDefinition xmlns="http://www.docusign.com/restapi">
<emailSubject>Email Subject.</emailSubject>
<status>sent</status>
<documents>
<document>
<name>1</name>
<documentId>1</documentId>
</document>
</documents>
<recipients>
<seals>
<sealSign>
<recipientId>1</recipientId>
<routingOrder>1</routingOrder>
<recipientSignatureProviders>
<recipientSignatureProvider>
<sealName>a6176xxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx</sealName>
</recipientSignatureProvider>
</recipientSignatureProviders>
</sealSign>
</seals>
</recipients>
</envelopeDefinition>
I get following error in the envelope audit.
Protect and Sign Demo (Client ID: dde5xxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx) replied: Error - ILLEGAL_DATA - Http error connecting to https://demo.docusign.net/restapi/vdev/signature/signhashsessioninfo Code 400 {"errorCode":"UNSPECIFIED_ERROR","message":"An Error Occurred."}
What am I doing wrong ?
The envelope status stays as "sent".
My expectation is it should be "complete" and seal applied in the document.
The vdev path is limited to DocuSign applications. You should be using .../v2.1
Also, you need the seal functionality to be enabled for your demo sandbox account. Contact go-live#docusign.com (include your account id) to have this done.
I have Azure B2C with custom policies with Local Login and Microsoft Account login enabled. I have started with the starter pack and made some modifications to add my custom logic for validate and add additional claims as explained here.
Everything works fine with Microsoft Account. But I am facing issues with Local Account Sign in.
email claim is only populated when the user signup but not on sign-in. In case of sign-in the email is part of "signInNames.emailAddress" claim. I tried making changes as explained here and here. I would like the email to be populate in email claim as my API uses this claim.
Additional calims returned from my REST API are not added to token only for Local Login. They are added for Microsoft Account.
thank you.
Update: For point 2, its a problem with my policy file and is now fixed.
There is a simple method to return email claim.
Just replace <OutputClaim ClaimTypeReferenceId="email" /> with <OutputClaim ClaimTypeReferenceId="signInNames.emailAddress" PartnerClaimType="email" /> in your SignUporSignIn.xml file.
You need to sign up new local user and then sign in to test it. You will see the email claim.
In fact, this solution has been provided by #Wayne Yang in the post you shared.
We have written a custom claims provider for ADFS. It's all working fine: you enter your username and credentials in our login page, and it authenticates you to ADFS. There's just one annoying omission: if you come from Office 365 portal and enter your email address, you get redirected to ADFS, then to our login page... but without the email address. You have to re-enter it before you can login.
I can't see anyway to request that ADFS forwards the email address as part of the SAML request, or to check if there is already an email address associated with the SAML request.
Regards
Robin Withey
I think you need to look into the UID and Mail attributes of the SAML response...
<saml:Attribute Name="uid" NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:basic">
<saml:AttributeValue xsi:type="xs:string">test</saml:AttributeValue>
</saml:Attribute>
<saml:Attribute Name="mail" NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:basic">
<saml:AttributeValue xsi:type="xs:string">test#example.com</saml:AttributeValue>
</saml:Attribute>
I'm working on a REST API that sends a confirmation email for a custom policy. Can anyone tell me if there is a way to pass the current culture so I can send a localized email?
You can add an <InputClaim /> to the REST API technical profile for passing the current culture as follows:
<InputClaim ClaimTypeReferenceId="mkt" PartnerClaimType="mkt" DefaultValue="{Culture:RFC5646}" />
where "mkt" (market) is an example of a claim type that you can replace with your own one.
"{Culture:RFC5646}" is known as a claims resolver.
Be sure to add the claim type to the TrustFrameworkPolicy/BuildingBlocks/ClaimsSchema section.