API Validation Change for Custom Terms

For those using the 'Custom' term setting (Spring, Summer, Fall, etc.) we have included a new validation to the 'dateStart' and 'dateEnd' fields.

 

When proposing dates for these terms from the API you will need to post the date that corresponds to the term, ie. (sample scenario) 2017-01-01 is the Spring 2017 Term. So if you need a course to Start in the Spring 2017 Term the only acceptable 'dateStart' will be 2017-01-01. 

 

The 'dateEnd' must be the date of the final term ie. if you have a course whose End Term is Spring 2017, the 'dateEnd' value must be 2017-01-01, that will be the only acceptable date for a course ending in the Spring 2017 term. CM recognizes that date as the Spring 2017 term and it will only become a 'Past' version when you transition to the next term, not on the date that is in the 'dateEnd' field.

 

When using the custom terms, you need to think of the dates themselves as terms and not as dates. 

 

The API will now respond with an 'Error 406: Unacceptable' error if the date is wrong.  It will post a status message that gives a list of "correct" term dates to use: 

 

"validations": [

        "dateStart is not a valid term date. Here are some examples of valid terms: 2017-01-01, 2017-04-03, 2017-07-04, 2017-10-04, 2018-01-01",

        "dateEnd is not a valid term date. Here are some examples of valid terms: 2017-04-03, 2017-07-04, 2017-10-04, 2018-01-01, 2018-04-03"

 

The actual status message you receive will reflect the valid term dates for your specific environment.