I created a template by the UI, and use it to create envelopes through the rest API. So far so good.
In the template, 4 roles were created. But one of these should be optional when creating the envelope, that is, in certain envelopes there will only be 3 signers.
The problem is that if I only send information for 3 templatesroles the docusign returns an error of INVALID_EMAIL_ADDRESS_FOR_RECIPIENT, for the role that was not informed.
My question is if there is a way to create a "optional" role in template. Which will only be informed in some envelopes.
Edit:
I'm creating the envelope with the status "created". I do that bc we have to add some documents to the envelope before sending. After that I update the envelope changing the status to "sent".
The error happens when I update the status to "sent". If I create the envelope already with the "sent" status the error doesn't happens.
Here's my code:
$result = Docusign::createEnvelope(array(
'templateId' => $saleContract->obra->template_id,
'emailSubject' => 'Contrato de Compra - ' . $saleContract->obra->nome_fantasia,
'status' => 'created',
'templateRoles' => $this->getRoles($saleContract, $tabs),
));
$this->addDocuments($saleContract, $result['envelopeId']);
//HERE IS WHERE THE ERROR HAPPENS
Docusign::updateEnvelope($result['envelopeId'], ['status' => 'sent']);
By default, template roles are optional. This means that you can successfully do the following:
Create a single template that contains the maximum number of recipients (and fields/tabs for all recipients).
Each time you create an Envelope via API, include Recipient information in the "Create Envelope" API request only for the needed recipients (Roles).
Any Recipient Roles that you do not specify information for when you POST /envelopes will not be included. In the event you want to create your envelope in draft, make modifications, and then send, set the "merge roles on draft" qp to true.
merge_roles_on_draft string
When set to true, template roles will be merged, and empty recipients will be removed. This parameter applies when you create a draft envelope with multiple templates. (To create a draft envelope, the status field is set to created.)
If you're still having problems, double-check that you haven't prepopulated your template role with name or email values. That will fudge up the merge ^
Related
I need to access the source of an email body through PowerAutomate. Unfortunately the standard HTML to Text - Body solution doesn't work as the emails I want to watch have an embedded link to our ERP (Coupa) and I only get this:
[https://urldefense.com/v3/__http:/www.coupa.com__;!!longstring]
When checking the source of the email body (or actually opening the email), the string I'm looking for is there but Google failed me on how to actually get the source of an email instead of the above conversion.
Full scope: watch inbox for automated emails generated for supplier registration requests, add row to spreadsheet with supplier's name, material group (regex match) and responsible person (xlookup in the table)
Using Compose - Body instead of HTLM to Text gets the source of the email body.
So I'm currently in an attempt to make my own account verification system and I'm using some parts of Djoser as a reference. let me try to walk you to my question
Let's say you're to make a new account in Djoser app
you put in the information of your soon to be made account including email
submit the form to the backend
get an email to the whatever email account you put in earlier to verify your account
click the link in your email
get to the verify account page
now in this page there's a button to submit a UID and a token and both of those information lies in the URL.
My question is:
What are those tokens? is it JWT?
How do they work?
How can I implement that in my own projects without djoser?
The answers to your questions are immersed in the own code of djoser.
You can check djoser.email file and in the classes there, they are few methods get_context_data().
def get_context_data(self):
context = super().get_context_data()
user = context.get("user")
context["uid"] = utils.encode_uid(user.pk)
context["token"] = default_token_generator.make_token(user)
context["url"] = settings.ACTIVATION_URL.format(**context)
return context
So get the context in the class where is instance, and in this context add the 'uid' (this is basically str(pk) and coded in base64, check encode_uid()), the 'token' (just a random string created with a Django function from your Secret key; you can change the algorithm of that function and the duration of this token with PASSWORD_RESET_TIMEOUT setting) to use temporary links, and finally the URL according the action which is performed (in this case the email activation).
Other point to consider is in each of this classes has template assigned and you can override it.
Now, in the views, specifically in UserViewSet and its actions perform_create(), perform_update() and resend_activation(), if the Djoser setting SEND_ACTIVATION_EMAIL is True, call to ActivationEmail to send an email to the user address.
def perform_create(self, serializer):
user = serializer.save()
signals.user_registered.send(
sender=self.__class__, user=user, request=self.request
)
context = {"user": user}
to = [get_user_email(user)]
if settings.SEND_ACTIVATION_EMAIL:
settings.EMAIL.activation(self.request, context).send(to)
...
The email is sent and when a user click the link, whether the token is still valid and uid match (djoser.UidAndTokenSerializer), the action activation() of the same View is executed. Change the user flag 'is_active' to True and it may sent another email to confirm the activation.
If you want code your own version, as you can see, you only have to create a random token, generate some uid to identify the user in the way that you prefer. Code a pair of views that send emails with templates that permit the activation.
We submit a CreateRecipient request to get a document signing URL:
https://developers.docusign.com/docs/esign-rest-api/reference/envelopes/envelopeviews/createrecipient/
To identify the user we provide user_id and client_user_id as per documentation(client_user_id has a valid string value). And most of the time but in a fraction of cases it fails with the following:
{
"errorCode": "UNKNOWN_ENVELOPE_RECIPIENT",
"message": "The recipient you have identified is not a valid recipient of the specified envelope."
}
We request values for user_id and client_user_id from the Envelopes -> Get Envelope envelope -> recipients -> signers, so there is no chance id's are incorrect.
DocuSign_eSign::Signer
#client_user_id="gid://platform/Client/617983",
#delivery_method="email",
#embedded_recipient_start_url="SIGN_AT_DOCUSIGN",
#recipient_id="1",
#recipient_id_guid="98e4bd97-a0b0-4c66-8b5d-7cca21813b04",
#recipient_type="signer",
#require_id_lookup="false",
#require_upload_signature="false",
#role_name="Client",
#routing_order="1",
#user_id="ad1bed21-ef62-4f37-af4c-909b0e95e7e3">
and the request is:
{
"authenticationMethod": "none",
"clientUserId": "gid://platform/Client/617983",
"returnUrl": "...",
"userID": "ad1bed21-ef62-4f37-af4c-909b0e95e7e3"
}
Using email and userName for the same failing envelope doesn't help.
We assume there is a bug in API, but it's hard to tell which signer actions activate such malfunctioning.
Recently affected envelope ids:
[
"357ed66b-866a-42c5-9304-23931a6daaee",
"9a900c0b-ca76-45ac-818b-3e38e1a0638a",
"5eb84ec3-a7ef-47a0-94bd-2842fe768f93",
"98934b17-674a-4be2-a6f3-2767821de395",
"05a09768-c3d6-4fe8-9654-85ce3e07b276"
]
We have checked this question: UNKNOWN_ENVELOPE_RECIPIENT but the recipients actually do match but since we identify signer by userID and clientUserID it doesn't seem relevant. Anyways we checked the recipient via by listing recipient and it matches perfectly.
PS Signing via email link works though.
I looked in the logs and saw the same thing you're seeing.
The request is for the wrong user/recipient.
Typically, when specifying these:
view_request.email = signer_email
view_request.user_name = signer_name
They have to match exactly (including case) to what's in the envelope.
If you use a userId, that has to match to how the envelope was sent. I would confirm that using email and user_name should work if you put the correct values. You can find these values by doing a GET on the envelope with all information included.
This is the Scenario:
In the same Azure tenant, I used one account (user_1_address) to send emails to the other account (user_2_address) using outlook (o365).
I sent 3 emails, one where user_2_address is BCCed, one CCed, and one when it's the TO recipient.
I'm using Microsoft graph API to get a list of emails received by user_2_address in a specific time range, using this query:
https://graph.microsoft.com/v1.0/users/{<user_2_id>}/messages?$filter=
receivedDateTime ge <some date> and receivedDateTime lt <some other date>
and isDraft eq false
and sender/emailAddress/address ne '<user_2_address>'
I'm getting all the three emails user_2_address had received from user_1_address. But in the email user_2 was BCCed the bccRecipients list is empty, when it should contain user_2_address :(
I have seen this question about sending an email from Gmail and BCC an outlook user:
Microsoft graph API: empty BCC field
In that case, also the bccRecipients list was empty, but it was resolved by saying the BCC is removed when sending the emails from an external source (Gmail in that case). When for me it's not an external source - both users are using outlook in the same tenant.
So my questions are:
Is it the desired behaviour, or is it a bug?
Now, let's say I'm using the query above where I get all emails where the sender is not the user_2_address and it's not a draft. Can I assume that every email I get where user_2_address is not in the ccRecipients and toRecipients lists - that email was BCCed to user_2_address?
Thanks!
The bcc field in a Message is an envelope (P1) recipient only so you should always expect that it will be blank (no matter the context inside a tenant really make no difference). Like the other post referenced if it wasn't blank it would break the RFC and the purpose of a BCC, the only exception is the sent item (which is just a copy of the sent message)
No there are many scenarios that would break that particular logic eg forwarded email is one the comes to mind. You could certainly refine you result set that way, one thing you might want to examine is the X-MS-Exchange-Organization-Recipient-P2-Type: mail header that should get set in your internal to internal scenario (you need to look at the PidTagTransportMessageHeaders extended property to see it)
In the Zend Framework 2 application I'm currently developing with Apigility there is a resource address, that provides following access points:
GET /address
id <-- required
PATCH /address
id <-- required
street
zip
city
type
OK. Now I started implementing a futher one for inserting items:
POST /address
street
zip
city
type
Since in the context of the POST method the id is not needed, it hence cannot be required. The problem is, that in Apigility there is no context dependent fields / fieldsets (yet?). So in order to implement the POST method, I have to make the id field not-required for all methods. But then I have to make them required for GET and PATCH manually (yet don't know how).
Is it possible to define context dependent fields / fieldset in Apigility? (Maybe I simply didn't find this option.)
If not: Which approaches are there to handle this?
Apigility does support verb specific validators. Validators are only applied or needed on POST, PUT and PATCH though. DELETE and GET do not take any body and that's the only part of a request that Apigility supports validation on.
Additionally, it's probably unlikely that you want the user of your API to supply the id. This is pretty rare. As you've indicated in POST, the id would likely be generated. This means also that the id would be provided for PUT and PATCH, but it should be part of the URL.
For example:
PUT /address/4
PATCH /address/5
In your route, you should have something like /address[/:id]. Based on whether or not this id is provided will determine what method is called in your resource class. PUT without the id (PUT /address) would call replaceList, while PUT with the id would call update. PATCH with an id calls the patch method. It doesn't really make sense to have PATCH without an id.
If you want to constrain the values in the URL, you can add a constraints section to the route's options like so:
'router' => array(
'routes' => array(
'your-api.rest.address' => array(
'type' => 'Segment',
'options' => array(
'route' => '/address[/:address_id]',
'defaults' => array(
'controller' => 'YourApi\V1\Rest\Address\Controller',
),
'constraints' => array(
'address_id' => '[0-9]+',
),
),
),
),
),
)
The key for constraints should match the name of the id variable in your route. The value would be a regular expression that matches the possible legitimate values for the id. You don't include regex delimiters for this. It will make requests to something like /address/banana return a 404 and the request will not make it into your resource's code.
With this in place, I'd recommend removing the id field from your fields list. You'll likely be able to use the same set of validators for POST, PUT and PATCH. It's important to understand how the validators are applied depending on the verbs as well.
In all the verbs, if you've configured filters, those will be applied to the supplied fields before validation. This means, for instance, if you have a filter of \Zend\Filter\Digits, then all non-digits will be removed prior to validation. If your validator is something like \Zend\Validator\Digits, then as long as the field contains at least one digit, it will be valid.
There are slight differences in how the validators are applied based on verbs. In POST and PUT (with an id in the URL), you can include extra fields that are not specified in your validators. In PATCH, there will be an error if you send in any fields which are not specified in the validators.
For PUT without an id (routing to replaceList), the expected body will be an array of objects.
The final caveat with the validators is that if you have filters applied to any fields and the validation passes, the values in $data that are passed into any of the methods will be the values before filtering is applied. Going back to the earlier example with a field that has the Digits filter and the Digits validator, if you send in something like {'my_field': '1234banana56'}, it will pass the validation but the value in $data will not be 123456, it will be 1234banana56. If you want to get the filtered value, you need to do something like this:
$filteredData = $this->getInputFilter()->getValues();
This will give you back an array of the filtered and validated field values. Any fields that were not specified in your validator will not be returned in this array. There has been talk about making this behavior configurable so that $data would receive the filtered data values, but as of this writing, that's how it works.
If you do find that you need different validators based on different verbs, the answers are in the docs here: https://apigility.org/documentation/content-validation/advanced
Hope this all helps.