Desire2Learn Valence API Creating and updating sections? - desire2learn

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)
}

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

Extracting specific values from a dictionary in iOS Shortcuts to display in a Choose from List menu?

I have a REST endpoint that returns a body that looks like this:
"posts": [
{
"message": "This is another message",
"created": "2019-12-27 21:33:54+10",
"items": [...],
"tags": [...],
"toot_id": "12345"
},
{
"message": "This is a message",
"created": "2019-12-26 20:42:15+10",
"items": [...],
"tags": [...],
"toot_id": "12344"
}
]
I want to extract just the message and toot_id fields and use a "Choose from List" action to display the message text, and upon selection pass the corresponding toot_id of the chosen message to the next action. Unfortunately I'm greatly struggling with how to do this... I know Javascript and TypeScript and can handle this sort of thing in those languages with no problems, but iOS's Shortcuts app is thwarting me. I've got as far as a "Repeat with each item" with the posts key as a result of hitting my REST endpoint, but I'm stuck as to how to continue from there, and I'm not clear on whether I should be setting the various actions inside the loop to "as Text" or "as Dictionary" either.
Thanks!
This is a screenshot of how I got it to work in a similar situation.
The key for me was the combination of "Get dictionary from Input" (use the variable), "Set Dictionary Value", and then "Set Variable". Trying to do "Set Dictionary Value" on the variable directly (in one step) never worked.

Pre-setting values to Docusign template

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.

HL7-Fhir : when posting a resource, is it allowed to reference to another resources by search criteria?

Creating a new resource (patient) can be done by a POST to the server.
Example 1]
Create a new Patient 'a' which is linked to Organization with id = 1) :
{
"resourceType": "Patient",
"name": "a",
"birthDate": "1974-12-25",
"organization": {
"reference": "Organization/1"
}
}
However, I was wondering if it's also allowed to create a new Patient with a link to an Organization based on a search field?
Example 2]
Create a new Patient 'b' which is linked to an Organization with name = orgname.
{
"resourceType": "Patient",
"name": "b",
"birthDate": "1974-12-25",
"organization": {
"reference": "Organization?name=orgname"
}
}
A reference must point to a specific resource. So what you've shown isn't allowed. However, if you were to post a bundle, your Patient resource could point to an Organization resource within the Bundle and the Bundle could have a conditional create (using If-None-Exist) based on the absence of any resource that has a specified name. But we haven't actually defined what happens to references in this circumstance. (If you wouldn't mind, it'd be good to submit a change request on this.)

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