Pre-setting values to Docusign template - ruby-on-rails

I am new to Docusign api and I am trying to post values from my form into a template. To be honest, I am not sure if I even created the custom fields properly or if there is some special way to set them into the form other than just creating a text field with a name.
I have read through the docs and recipes and about a dozen or more stack posts.
I am using rails and my fields post just fine but it's my tabs that do not. I read somewhere that I am supposed to use tabs and not custom_fields. Not sure if that's totally correct but that's how I've interpreted it.
Here is my current code:
body: {
"emailSubject": "DocuSign API call - Request Signature - Boom",
"templateId": "e1d5bce1-9757-4ffe-881b-054aa9139f2f",
"templateRoles": [{
"email": "#{renter.email}",
"name": "#{renter.background.legal_name}",
"roleName": "Lessee"
},{
"email": "#{#manager.email}",
"name": "#{#manager.name}",
"roleName": "Lessor",
"tabs": {
"texttabs": [{
"tabLabel": "Rent",
"value": "#{#lease.rent}"
},{
"tabLabel": "Address",
"value": "987 apple lane"
}]
}
}],
"status": "sent"
}.to_json
baseUrl that I am sending to:
"https://demo.docusign.net/restapi/v2/accounts/my_id/envelopes"

In your texttabs section, you should be passing in the following parameters at a minimum per tab: tablabel & value.
tablabel is the name of the tab that you have defined on the template. So from what I can tell, you have a text box on your template called Address. So you should put "tablabel":"Address".
value is what you would like to pre-populate in the tab. Looks like you have that correct.
You do not want to use tabID as that is not a valid parameter in this flow. The API documentation details what parameters you can use: https://www.docusign.com/p/RESTAPIGuide/RESTAPIGuide.htm#REST%20API%20References/Tabs/Text%20Tab.htm?Highlight=data%20tab
I also see an extraneous parameter of "Rent" under templateRoles section. That value will be ignored since it is not a valid parameter.

Turns out the problem was not with the code but with the setup within docusign. Make sure that you are setting up your tabs correctly and if you want to replicate a field multiple times make sure that they all share the same exact name.

Related

How to return friendly field names for zapier trigger (zapier developers)

I am working on a Zapier integration for an online form builder. Each unique form for our users has lots of long, auto-generated field names.
We have a trigger called “New form entries”, which polls our server for form entries, and comes back like this:
[
{
"id": "6209aee326baa600224d822c",
"email_907058157108782": "test#test.com",
"phone_589083232390193": "12345",
},
{
"id": "61fd629f19408200225e1893",
"email_907058157108782": "test#test2.com",
"phone_589083232390193": "54321",
},
]
However, this results in end users seeing these really long, gross field names in the Zapier interface:
My question: how do I get Zapier to display friendly labels to the user, whilst using the unique field IDs behind the scenes?
I’m thinking of returning something like the following (each object represents a form entry, , but I need to know how to actually use “friendlyFieldName” and “value” in Zapier!-
[
{
// the id for the entry
"id": "62179ec5ab9daa0022df7d1d",
// the id for the first field entry
"text_576692390099896": {
// a friendly name and value for zapier
"friendlyFieldName": "What is your favourite colour?",
"value": "Blue"
}
}
]
Thank you :)
You can define output fields labels in outputFields. Here are the reference document that you can follow: Output Fields

In Power Automate, is there a way to filter on a Custom Field using DevOp's Send HTTP Request?

I'm trying to use Power Automate to return a custom work item in Azure DevOps using the "workitemsearch" API (via the "Send HTTP Request" action). Part of this will require me to filter based on the value of a Custom Field, however, I have not been able to get it to work. Here is a copy of my HTTP Request Body:
{
"searchText": "ValueToSearch",
"$skip": 0,
"$top": 1,
"filters": {
"System.TeamProject": ["MyProject"],
"System.AreaPath": ["MyAreaPath"],
"System.WorkItemType": ["MyCustomWorkItem"],
"Custom.RequestNumber": ["ValueToSearch"]
},
"$orderBy": [
{
"field": "system.id",
"sortOrder": "ASC"
}
],
"includeFacets": true
}
I have been able to get it to work by removing the Custom.RequestNumber": ["ValueToSearch"] but am hesitant to use that in case my ValueToSearch is found in other places like the comments of other work items.
Any help on this would be appreciated.
Cheers!
From WorkItemSearchResponse, we can see the facets (A dictionary storing an array of Filter object against each facet) only supports the following fields:
"System.TeamProject"
"System.WorkItemType"
"System.State":
"System.AssignedTo"
If you want to filter RequestNumber, you can just set it in the searchText as the following syntax:
"searchText": "RequestNumber:ValueToSearch"

"additional properties" error in Survey Monkey API call

I'm trying to use the create_flow endpoint to the Survey Monkey API. It is sending back a status 3 message with the following error:
additional properties not defined by 'properties' are not allowed in field '_data'
I'm able to do successfully use all other API endpoints and have a valid API key and durable OAuth token.
Here's an example JSON body that I'm sending to: https://api.surveymonkey.net/v2/batch/create_flow?api_key=apikeyhere
{
"survey": {
"template_id": "566",
"survey_title": "test1",
"collector": {
"type": "email",
"name": "collector1",
"recipients": [
{
"email": "email#example.com"
}
]
},
"email_message": {
"reply_email": "myemail#example.com",
"subject": "this is a test"
}
}
Note: JSON formatting here is being generated automatically using RJSONIO
Any ideas what might be causing the error? It seems like all fields are correctly named and where they're supposed to be, so I'm not sure what the problem is.
It's a bad error message unfortunately - it's a known issue. It means you are providing extra keys that are not part of the create_flow schema.
The issue here is that the "email_message" and "collector" keys have been nested inside of "survey", instead of being in the main JSON body like the "survey" key. Move them out a level and it should work.

Desire2Learn Valence API Creating and updating sections?

I am working on integration with our university's SIS system and am stumbling a bit with the documentation related to creating and updating sections. http://docs.valence.desire2learn.com/res/enroll.html#Section.SectionData
I can use the route PUT /d2l/api/lp/(version)/(orgUnitId)/sections/ to create a default section named Section 1 with section code sec1 however when I try to update it or add an additional section with the routes: PUT /d2l/api/lp/(version)/(orgUnitId)/sections/(sectionId) (with the sectionId retrieved from my previous PUT) or POST /d2l/api/lp/(version)/(orgUnitId)/sections/
I am using the following block for my json data:
{
"Name": "Section 1d",
"Code": "Dan 101",
"Description": {
"Text": "",
"Html": ""
}
}
What am I missing in the syntax?
Thank You
The way you use the Valence Learning Framework API to create sections for course offerings is idiosyncratic. Assume you start with a blank course, that has no descendant org units (no sections, no groups, nothing):
GET /d2l/api/lp/1.3/orgstructure/113459
> {"Name": "Extensibility 106",
"Identifier": "113459",
"Type": {"Name": "Course Offering",
"Code": "Course Offering",
"Id": 3},
"Code": "EXT-106"}
GET /d2l/api/lp/1.3/orgstructure/113459/children
> []
Initialize course with section properties. The first thing you have to do is define the section properties for the course offering: what kind of sections do you want to create under the course offering? To create the section properties for the course offering, you use a SectionPropertyData block; here's one that says "I want this course to have 10 sections and to auto-enroll the students, randomly, into these sections" (EnrollmentStyle 2 corresponds to NumberOfSectionsAutoEnrollment):
{"AutoEnroll": true,
"EnrollmentQuantity": 10,
"EnrollmentStyle": 2,
"RandomizeEnrollments": true}
Now, to initialize the course with these settings, and have the first default section(s) created, we PUT that block to this route:
PUT /d2l/api/lp/1.3/113459/sections/
> [{"SectionId":113460,
"Name":"Section 1",
"Description":{"Text":"","Html":""},
"Enrollments":[]},
...
{"SectionId":113469,
"Name":"Section 10",
"Description":{"Text":"","Html":""},
"Enrollments":[]}
]
Notice that with this call, we've now created 10 sections as children of this course offering, and the back-end service has automatically generated names (and codes) for them.
Add a new section after the fact. Now suppose we want to add an eleventh section to this course. First, we need to use a SectionData block for the new section's properties:
{"Name": "Section 11",
"Code": "Sec11",
"Description": {"Content": "New Section Descr.", "Type": "Text} }
(Note: When you form this block to create the new section you have to use a RichTextInput type structure for the Description property. When you get the properties for a section back from the service, it writes the description using the RichText property instead. This is a common sticky point for devs new to the framework)
Then, you POST that block to this route:
POST /d2l/api/lp/1.3/113459/sections/
> {"SectionId":113470,
"Name":"Section 11",
"Description":{"Text":"Description","Html":""},
"Enrollments":[]}
You'll get back the properties for the newly created section.
Summary. So, "why PUT and then POST"? Yes, it is a bit confusing, but think of it this way:
The first use, of PUT, is to update the "section properties" attribute for a course offering (as a consequence, when a course offering's section properties are initially defined, as a side effect, the back-end creates the section org units needed to go along with those new settings).
The second use, of POST, is to create a new org unit (a new section), and assign it to the course offering.
It looks like your routes and your request are okay. Only one small change with the route. You need to use the RichTextInput field that is described in the documentation D2L Conventions
Basically instead of:
"Description": {
"Text": "",
"Html": ""
}
You need:
"Description": {
"Content": "",
"Type": "" (Either Text or Html)
}

Unable to create course via api

I am trying to create a course in a semester through the api in valence d2l. I keep getting a 404 not found error, both in my program and in the "getting started" application. The call I am making is to /d2l/api/lp/1.0/courses/ using post. I pass the following JSON object along with it:
{
"Name": "COMM291 - Test A",
"Code": "C-COMM291",
"Path": "/enforced/C-COMM291/",
"CourseTemplateId": 20992,
"SemesterId": 20993,
"StartDate": "2013-08-22T19:41:14.0983532Z",
"EndDate": "2013-08-27T19:41:14.0993532Z",
"LocaleId": 4105,
"ForceLocale": false,
"ShowAddressBook": false
}
I have also tried passing null for the fields that say they accept null values, but no luck. The course template and the semester ID are correct - I have tripled checked that they exist, I am enrolled in them and I am using the correct ID numbers.
Try reducing the precision in your start and end dates to three decimals after the final point (e.g., "2013-08-22T19:41:14.0983532Z" becomes "2013-08-22T19:41:14.098Z").
If your org is configured to automatically enforce, and generate, paths for course offerings, then you should not provide one in your CreateCourseOffering block at all. The following structure works on our test instance: notice the empty string for path (shouldn't be null, but an empty string, I believe):
{ "Name": "Extensibility 104",
"Code": "EXT-104",
"Path": "",
"CourseTemplateId": 8082,
"SemesterId": 6984,
"StartDate": "2013-09-01T19:41:14.098Z",
"EndDate": "2013-12-27T19:41:14.098Z",
"LocaleId": 1,
"ForceLocale": false,
"ShowAddressBook": false }
The other thing to note is that if your CreateCourse form doesn't have a form element to provide a Semester ID, then your API call should pass null for that property.
I found that part of my problem was with the call if I change it to /d2l/api/lp/1.3/courses/ instead of 1.0 it works, (1.0 will work but it seems that you can only pass null for the semester).
The dates were also picky and did prefer milliseconds to only 3 decimal places.
Then passing null for LocaleId also helped.

Resources