Setting a Due Date on a Topic

[Luc Aube]

Hey Guys,

We are having problems setting a due date on a Topic with Valence. The other fields in the same api call are getting updated without any issues. I have a demo of a topic get and post in the bottom. As you can see the Start Date and End Date get updated. But the Due Date remains null after we get the topic on the second pull after the Put.

I summarized our actions to get a clearer understanding of the issue we are experiencing.

We are doing 3 apis Calls. Get Topic, Update Topic then another get Topic to test if the update was successful.

GET TOPIC 729

/d2l/api/le/1.4/6622/content/topics/729

Return JSON

{"DueDate":null,"TopicType":1,"Url":"/content/enforced/6622-BUS3052014/Content/page_4752.html","StartDate":null,"EndDate":null,"IsHidden":false,"IsLocked":false,"Id":729,"Title":"1. Read This First","ShortTitle":"","Type":1}

MODIFY Topic 729

/d2l/api/le/1.4/6622/content/topics/729

Request JSON

{"TopicType":1,"Url":"/content/enforced/6622-BUS3052014/Content/page_4752.html","StartDate":"2014-04-20T13:15:30.067Z","EndDate":"2014-08-20T13:15:30.067Z","DueDate":"2014-05-20T13:15:30.067Z","IsHidden":false,"IsLocked":false,"Title":"1. Read This First","ShortTitle":"","Type":1}

Return code 200 Ok

GET Topic 729 After the Modify Topic

/d2l/api/le/1.4/6622/content/topics/729

Return JSON

{"DueDate":null,"TopicType":1,"Url":"/content/enforced/6622-BUS3052014/Content/page_4752.html","StartDate":"2014-04-20T13:15:30.067Z","EndDate":"2014-08-20T13:15:30.067Z","IsHidden":false,"IsLocked":false,"Id":729,"Title":"1. Read This First","ShortTitle":"","Type":1}

As you can see the End Dates and Start Date was updated correctly but the Due Date stays null.

Thanks

Luc

[Desire2Learn Staff: Viktor]

Hi Luc,

I'm sorry that I haven't been able to respond sooner yet. I am looking  into this issue. I suspect that this is actually a role permission issue in that the role permissions required to alter the DueDate item on a property might be different to the role permissions required to alter other properties on a topic. Once I can reproduce (or not) this behaviour on a test instance here, I will follow up again with more detail.

[Desire2Learn Staff: Viktor]

Luc, I was able against a test instance to alter the DueDate of a content topic of the same type as yours (an in-place HTML content topic, of type 1, topic type 1). I used the same date structure that you did -- the same values for StartDate, EndDate, and DueDate. It has the same visibility properties: False for IsHidden and IsLocked.

I tested with a user/role that started with no role permissions, but was explicitly enrolled in the test course offering.

After ensuring the user's role had these three permissions for the Content tool (at the Course Offering level only), I was able to update/retrieve the content topic and set the DueDate property:

- ViewCourseContent

- ManageContent

- Create and Edit Modules and Topics

Please verify that your user calling this API is explicitly enrolled in the course, and has these role permissions at the Course Offering level. This should work for you.

Also -- I verified that both updating and retrieval worked under v1.4 and the upcoming v1.5 of the API calls involved.

Hope this helps.

[timothy...@aspen.edu]

Viktor,

Thank you for the reply.  I worked with Luc and verified that those permissions are set to the user we a performing the API calls with.  Our "API User" is part of the "Administrators" role, after verifying that those permissions were set at the course offering level we are still unable to update the due dates, using the above PUT string.

We decided to test our GET string again, after we added a DueDate manually through the LE, we are now able to view the DueDate in the return JSON.

I also tried creating a role with only the permissions mentioned above and still aren't able to modify the DueDate.

Please advise.

Thanks,

Tim

[Desire2Learn Staff: Viktor]

On the GET route, I'm pretty sure that in order to see the DueDate property back through the API, you have to use the appropriate API version (i.e. a version number of 1.3 or greater)... a GET call with an older API version number embedded likely will get back a structure without the DueDate property.

On the update point, this inconsistency is troublesome. Can you let us know what version of the back-end LMS you're calling, including service-pack level if you can, please? I will then try to do further testing at this end to reproduce against an LMS build that's more directly similar to your own (my testing was done against a head-rev developer build).

[timothy...@aspen.edu]

We are calling version 1.4 and here is the other information you requested:

Product Name	Version
Integration and Middleware Platform	1.5.1 SP1
IP Authentication Solutions	1.2.1
Learning Environment	10.3.0 SP6
Learning Platform	5.3.0 SP6
Reporting	4.4.5

[Desire2Learn Staff: Viktor]

I'm assuming that, at the time you were testing this, the DueDate was a date in the future? I don't think that should matter, actually, because I was testing successfully with your date value yesterday, when it was already in the past, so it shouldn't be a factor. But it might be something to try.

[timothy...@aspen.edu]

We tried that also using different dates.

To answer your other question from the PM, we tried using a user that was explicitly enrolled into that course offering, and also with a user that was enrolled via cascading enrollment.

Thanks,

Tim

[Desire2Learn Staff: Viktor]

OK -- thanks for the info, Tim.

[Desire2Learn Staff: Viktor]

OK -- I think I've managed to reproduce this on a v10.3.0 SP9 instance (please note that the SP9 instance may not yet be deployed -- I am testing against instances in D2L's QA environment). I'm currently trying to uncover if this change as part of a known defect, or known related defect. The next release of LE does seem to correct this issue you've discovered; however, the issue persists, as far as I can tell, in the current v10.3.0 service pack codeline.

Practically speaking, what this probably means is you can wait until a platform upgrade to get this rectified. If, however, you want to register this as a defect and potentially have it addressed in a future service pack for the v10.3.0 codeline, then I'd encourage you (or your organization's Approved Support Contact) to open an incident for this with our support organization, reporting it as a potential defect. If you do choose to do that, you can also PM me again with the incident number for the issue once created, and I can help to ensure it gets escalated and triaged appropriately for an API defect.

I realize that this isn't an optimal answer, but I hope it clarifies what the options are.