When updating built in fields (I haven’t observed this for custom fields) using the client side library (JSOM or CSOM or REST) in the normal way the following error can be reported in the queue unexpectedly:
CICONotCheckedOut: CICONotCheckedOut (10102). Details: id=’10102′ name=’CICONotCheckedOut’ uid=’a2da51ea-792b-e411-9af1-00155d908811′.
Queue: GeneralQueueJobFailed (26000) – ProjectUpdate.FailIfNotCheckedOutMessage. …
For example the following code from the MSDN article on this topic will intermittently get the above error:
// Get the target project and then check it out. The checkOut function // returns the draft version of the project. var project = projects.getById(targetGuid); var draftProject = project.checkOut(); // Set the new property value and then publish the project. // Specify "true" to also check the project in. draftProject.set_startDate("2013-12-31 09:00:00.000"); var publishJob = draftProject.publish(true); // Register the job that you want to run on the server and specify the // timeout duration and callback function. projContext.waitForQueueAsync(publishJob, 10, QueueJobSent);
This is despite the fact that we are obviously doing the check-out of the project in line 4.
- The update will still work for most fields (like Status Date but NOT for Project Owner), despite the error indicating otherwise!
- The error is not consistent, some updates work without an error.
Cause and Solution
Turns out the issue is one due to the asynchronous nature of the client side libraries, specifically it looks like when performing the “waitForQueueAsync” we are actually requesting four things:
- Check out Project
- Update project value (start date above)
- Publish Project
- Check project back in
However it seems that steps 2 and 4 don’t quite run in the correct order! Changing line 10 as follows to NOT check-in after publishing results in a successful update and no error:
var publishJob = draftProject.publish(false);
Then we need to add a separate checkIn() call AFTER the completion of the publish (IE in the callback function ‘QueueJobSent‘ above) and then call waitForQueueAsync again.
Looks like a bug although perhaps not as it is important to keep in mind that the queued async jobs are not guaranteed to be done in the correct order although clearly it usually happens in the order expected.
BTW, Yes expect an update for Bulk Edit supporting more built-in fields soon!