Can I add hidden metadata on the document level like you can through the API? In the DocuSign API, I can do the following in the document object:
new Document()
{
DocumentId = (i+1).ToString(),
DocumentBase64 = Convert.ToBase64String(request.Documents[i].Stream.ReadAsBytes()),
Name = request.Documents[i].Name,
DocumentFields = new List<NameValue>()
{
new NameValue()
{
Name = "DocumentType",
Value = "ElectronicConsent"
}
}
};
The DocumentFields specifies what that document is. Through the API, I can retrieve the document and its field:
EnvelopeDocumentsResult docList = envApi.ListDocuments(_accountId, envelopeId);
DocumentFieldsInformation docInfo = envApi.ListDocumentFields(_accountId, envelopeId, document.DocumentId);
Since I know what the returned document is, I can now run business logic on it. I'd like to allow users the ability to perform a similar action in the UI. This would allow the API to retrieve an envelope that did not originate in code, but the code still knows how to handle that type of document.
I tried the following:
I created a "Document Custom Field."
The "Document Custom Field" is of type "Drop Down" and contains various known document types.
I modify the custom field so that it is white and read only (the signer won't be able to modify it).
Before sending the envelope/document, I add this custom field to the form and select the correct document type.
I send the document.
When I run the same API method to retrieve "Document Fields," the value doesn't get returned. It appears that manually placing the field on the document results in the field being part of the "form" instead of metadata.
You cannot set Document Field as you can set it in an API. The Document Custom Field which you are setting is just another reusable DocuSign tab. So on WEBApp if you are planning to use Document Custom Fields, then your Connect listener should check for two things, one document fields which will be coming from the API, and the Document Custom Field which will be coming as form data. When doing through WebApp, I will make that field white label on white text so that it is not visible to the customer, but it is present on the document. To make maintenance easier on your side, I would create two Connect listener, one just for API user who will be using Document Field, another for non-API/WebApp user who will be using these reusable Document Custom Fields, and write different logic on both listener.
Related
We are attempting to use the DocuSign API for eSignatures on items such as leases & automatic billing authorizations. What I have are a set of .rtf documents provided to me by our legal team, and there are certain sections that need to be replaced dynamically. I have looked through the DocuSign REST API docs, and I think what we are supposed to be using are text tags. Ware using the PHP SDK. I have not set this document up as a template, as it would be great if we could just use a local file on the filesystem and then have placeholders automatically replaced by values specified in our payload.
What we would like to do is have fields in our documents (such as TenantName and TenantAddress) that we can assign values to, and have DocuSign dynamically replace these placeholders with the values we specify. I have tried doing this using Text Tabs, but the values are not being replaced. Here is a code sample:
$document = new Document([
'document_base64' => $b64fc, // base64_encoded value of file_get_contents('path/to/document.pdf')
'name' => 'Autobill Form',
'file_extension' => 'pdf',
'document_id' => '1',
]);
$tag1 = new Text();
$tag1->setTabLabel('TenantName');
$tag1->setValue('Joe Signer');
$tag1->setLocked(true);
$tag1->setDocumentId('1');
$tag1->setPageNumber('1');
$tag2 = new Text();
$tag2->setTabLabel('TenantAddress');
$tag2->setValue('123 Main St.');
$tag2->setLocked(true);
$tag2->setDocumentId('1');
$tag2->setPageNumber('1');
$tabs = new Tabs();
$tabs->setTextTabs([$tag1, $tag2]);
$document->setTabs($tabs);
// other code to set up recipients, envelopes, and get an embedded signing url
When I view the document, these fields are not replaced, and still have their placeholder values. I don't want to use anchors as I need the placeholder to be removed and replaced by DocuSign. I have also tried setting the text tabs on the Signer object, but that did not work either.
What am I doing wrong? This seems like it would be a fairly common use case for the DocuSign API, but I haven't been able to figure this out.
As Inbar states, the DocuSign eSignature API doesn't allow you to modify the underlying document. You'd need to external tooling to prepare the document prior to passing it into the API Call.
That said, one possible option would be to have blank spaces in your document that align with Text tabs. If you pre-populate those tags and set them to be read-only, the placeholders tags will burn-in during the signing session. Spacing, alignment, and font likely won't be perfect, but with some adjustment you can do okay.
We have defined a template that will be filled in and signed by our customers. In this template we have some fields that we pre-populate along with some documents that we will attach. The customer will fill in other fields and attach more documents. We are using the REST API to generate the sign request. We are able to generate the correct REST request to fill the tabs in the template, set the recipients and successfully send the signature request. All this works great. But now we're trying to get a document attached to the appropriate SignerAttachmentTab in the template and we cannot get REST to accept it.
We've tried using the Documents field but that doesn't work with templates it seems. We created a composite template and then defined a document for the document, server template for the template itself and an inline template to contain the tab data we want to populate. This keeps generating errors about the tab page number not being right. We've tried different values and we've looked over all the forum posts and documentation related to attaching documents to templates and none of them seem to work.
For the document we specify the file to upload, set the document ID and name. In the server template we specify the template ID. In the inline template we create a recipient, set their information, build up the envelope tabs with the data and then add a SignerAttachmentTab for the document. In this tab we set the document ID to match the document ID from the Document element. We set the tabLabel to the label used in the template itself. We've tried setting pagenumber but that doesn't change anything. All we want is for the document to be sent to the customer. When the open it they can double click the attachment field and view the document we're trying to send.
I'm trying to use the recipe explorer to get this to work using raw REST and it keeps failing with the TAB_PAGENUMBER_IS_NOT_IN_DOCUMENT error. It seems like the document is taking precedence over the template. Unfortunately I cannot change the order of the templates in the editor other than setting the sequence # on the server and inline templates. Here's the request that is generated using DocuSign's test system.
{
"compositeTemplates":[{
"document": {
"documentBase64":"<Base64BytesHere>",
"documentId":"2",
"name":"Test.pdf"
},
"inlineTemplates":[{
"recipients":{
"signers":[{
"email":"abc#def.org",
"name":"Person",
"recipientId":"1",
"roleName":"Sender 1",
"tabs":{
"signerAttachmentTabs":[{
"documentId":"2",
"tabLabel":"MyAttachment"
}],
"textTabs":[{
"tabLabel":"someText",
"value":"Value1" }
]}
}]},
"sequence":"2"
}],
"serverTemplates":[{
"sequence":"1",
"templateId":"guid}]
}],
"emailBlurb":"A message",
"emailSubject":"Test",
"status":"sent"
}
I've looked at the existing posts in the forums and either they don't work for my case or they aren't trying to actually attach the documents to the template but simply include them as a document in addition to the template.
Update
Re:
...associate [a] document to the tab so that the signer will be able to click the attachment field in the document and see the document
Yes, you can now do this by using Smart Sections with a documentHtmlDisplaySettings object in the Envelopes:create request. The collapsed (or collapsible) section can be displayed in different ways:
inline
collapsible
collapsed
continue_button
responsive_table
responsive_table_single_column
print_only
Live examples that you can try online
HTML source document
Word source document
Original answer
Re:
But now we're trying to get a document attached to the appropriate SignerAttachmentTab in the template and we cannot get REST to accept it.
You're trying to use the API to add a document to a SignerAttachmentTab?
This is not supported. Only signers themselves add documents to a SignerAttachmentTab. The API can't do it for them.
Is the issue that you want to make sure that a signer attaches (uploads) a document to the envelope as part of the signing ceremony? You can make the tab non-optional (required). But that won't check the contents of the attached file.
You could use a web hook / Connect to check the file(s) that were attached and, if the right files weren't attached, generate another enveloper for the signer.
I figured out what I was doing wrong. For a template without attachments I was using TemplateRole and EnvelopeTabs. But for attachments, trying to include any document would cause the document to override the template. So I switched to composite template with server and inline templates for the template and data. Trying to add documents in various combinations in the various areas where they are allowed generally caused the request to be sent but with no documents.
The final solution was to go back to the original TemplateRole approach but to create the envelope as a draft. After the draft envelope was created I could then add the document to the envelope. But unfortunately to send the envelope you then have to reattach the recipients. I'm looking to clean that up but otherwise it is working for me now.
I have a Registration ContentType, which contains a ContentPicker field for a Building Item, which contains a Geolocation Part with some properties like Latitude and Longitude.
When a new Registration is Published, it triggers a custom Workflow that sends out an email. In the body of the email I can get to the fields of the Building using tokens like this: {Content.Fields.Registration.Building.Content.Fields.Building.Address}
How can I get to the property values of the Geolocation Part contained within the Building? Can I do something like this? {Content.Fields.Registration.Building.Content.Parts.Geolocation.Latitude}
I'm new to Orchard and I can't figure out how it's structured. Can this be done out of the box or will I have to write a custom token?
If you know which content item to take from the content picker field (for example if it always is only one), then the following might work:
{Content.Fields.Registration.Building.Content.Fields.Building.ContentItems[0].Geolocation.Latitude}
This is assuming your Building field is configured to pick content types with a Geolocation part
I am a newbie with SharePoint. I have set up a document library. One of the columns is a unique id for a document. Another column called Related Document is a lookup field that may contain a clickable link to another document's unique id.
How to automatically fill in related document column with the link to the original document? That is, if I make document A be related to document B, I would like to automatically add a relationship from B to A as well. Not sure if it's possible to do with Related items feature - it does not seem to allow a clickable link.
Thank you.
The only way I can realistically see this being done is with a Remote Event Receiver. https://msdn.microsoft.com/en-us/library/office/jj220043.aspx
I can't think of a way out of the box that would do this.
You will need to create a SharePoint Add-in and deploy it to your SP Online instance. The remote code will get hosted on an Azure instance.
The remote code will get triggered when a document is updated.
You can then get a reference to the related document and fill in the related document link field accordingly.
You can pass parameters with the source parameter of SharePoint. This is actually to forward an URL to jump back to, but can be used to automatically pass parameters to the second form of the library.
Here is a small function that opens an upload dialog e.g. to be inserted in a content editor WebPart:
function openUploadDialog(passParameterName, passParameterValue)
{
var dialogOptions = SP.UI.$create_DialogOptions();
dialogOptions.url = "/_layouts/15/Upload.aspx?List=[INSERT_LIST_ID_HERE]&RootFolder=&IsDlg=1&source=%2fSitePages%2f[SOME_SITE_OF_YOURS].aspx%3f" + encodeURIComponent(passParameterName) + "%3d" + encodeURIComponent(passParameterValue);
dialogOptions.width = 700;
dialogOptions.height = 310;
dialogOptions.title = "Submit Document";
dialogOptions.dialogReturnValueCallback = Function.createDelegate(null, CloseThisDocCallBack);
SP.UI.ModalDialog.showModalDialog(dialogOptions);
}
openUploadDialog([NAME_OF_YOUR_ID], [VALUE_OF_YOUR_ID])
Short:
Add a field with the ID (or whatever you want) to your Library
Create a Content Editor or script WebPart where every you want and use the
function to open a dialog
look at the source of this webpart to find out the DOM ID of the field
Add another webpart to your Upload Form (Ribbon => Library => Form Webparts => Default Editor Form) to take the value from the source paramter (e.g. via JQuery) and write it into the new field you've just created.
Something like this:
id = GetUrlKeyValue('[NAME_OF_YOUR_ID]');
$('#[DOM_ID_OF_YOUR_CUSTOM_FIELD]').val(id);
I used this once to add an ID of a list element to the file. Hope that this is what you were looking for.
I am using DocuSign Connect API to generate envelopes. I have a tab defined as a custom text field that is marked as required. I would like to pre-populate its value, and still give the signer the ability to edit the field.
When I populate the field with a string value, it is displayed to the signer but it is not editable. It is only editable if I fail to populate the field. I have verified that the 'CustomTabLocked' property is 'false', which I thought would have been enough to ensure the field's edit-ability.
Is the behavior I am seeking supported?
Posting an answer for the benefit of the community- when using the DocuSign SOAP API there is an XML property that you need set for certain properties. In this case to set CustomTabLocked to true you also need to set CustomTabLockedSpecified property to true.