cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 
matt_borja
Community Participant

SIS Import Not Removing Section For Relocation

Hello,

We currently have a ticket in with Canvas about this, but I wanted to go ahead and check with other developers while I wait for a response back and will try to make this as simple as possible.

We have been importing courses, sections, and enrollments for some time now. However, we've also had to modify our data structure which has necessitated sections to be completed relocated from one course to another and the process needs to be: 1) remove Section A from Course A and 2) re-create it in Course X.

Please bear in mind that Course A and Course X are mutually exclusive. They may look similar or have nothing in common at all. Whatever the case may be, we want Course X to have Section A and Course A to have no knowledge or association of Section A.

The problem is at some point in time, we used SIS to import Section A into Course A. Now, we want to delete it from Course A (status="deleted") and re-create it in Course X (status="active"). Deleting works and the section gets dropped. However, when we explicitly specify Course X's course_id in the CSV file to import (overriding stickiness, etc), the section gets re-imported back into Course A whose course_id is completely different.

So in other words, our process is (similar to what our CSV looks like):

  1. Delete: SECTION_A,COURSE_A
  2. Add: SECTION_A,COURSE_X

The expected result is: SECTION_A,COURSE_X

The actual [incorrect] result is: SECTION_A,COURSE_A

Has anyone else been experiencing the same problem here?

Note: We have been working very closely with the API and SIS imports and have carefully selected parameters (i.e. override stickiness) in place for what we need to do. Also, this is not the first time we've seen abnormal behavior following a deletion of an SIS-imported object where re-creation of an object or a property update would fail because it thinks it's still there when it's not.

8 Replies
N_YOUNG
Community Participant

Just a quick thought before the day gets away from me.... but why do you need to do the delete operation first?

If your new CSV has just the row to assign SECTION_A to a new course, then it should move it to the new parent.

I think you may have found a bug with the delete/restore issue of it putting back in the old parent... but my first thought when i read your post was to eliminate the DELETE step altogether.

That's how we do moves/reassignments all the time via SIS CSV import, and we haven't (yet) seen the issue you're describing.

Made up example to illustrate for sections.csv

SIS CSV #1

section_id - course_id - name - status - start_date - end_date

SECTION_AAA - COURSE_BIO-101 - Section AAA - Active - NULL - NULL

SIS CSV #2

section_id - course_id - name - status - start_date - end_date

SECTION_AAA  - COURSE_ENG-400 - Section AAA - Active - NULL - NULL

matt_borja
Community Participant

Hi Nicholas,

The reason why we need to delete is because this is a two-part job:

  1. Course A should not have that section so we need to delete it.
  2. Course X should have that section but our exhaustive testing have shown that there is some underlying "historical stickiness" that on import, the section is actually not getting added to the intended Course.

I mean literally, our SIS section import CSV looks like this:

section_id,course_id,name,status,start_date,end_data
"20153039639","201530CSA126PRE39639","Microsoft Office 2013","active","2015-08-24 00:00:00-07:00","2015-12-12 00:00:00-07:00"

But it's getting importing as if we were passing them this CSV (which we're not):

section_id,course_id,name,status,start_date,end_data
"20153039639","201530CSA126PRE39637","Microsoft Office 2013","active","2015-08-24 00:00:00-07:00","2015-12-12 00:00:00-07:00"

The reason they look very similar is because at one point this section was imported (via SIS) into this latter course and the course itself had two sections. After taking a step back and re-evaluating how we were implementing this with business needs, we decided we needed to modify this course-to-section relationship. However, it appears that because we already imported it in this manner once before, now Canvas is having an issue with us deleting altogether from the course it shouldn't be in and adding it to the course it should be in.

Another thing to note now is that we followed L1 support's advise to try creating a cross-list via SIS Import as an attempt to move the section. We found that to work beautiful on the first try. But in all fairness, that's really not what we're shooting for because (taking your example), if COURSE_ENG-400 ever gets deleted or the cross list ever gets deleted, etc. SECTION_AAA (which is now an English section) will snap right back to COURSE_BIO-101 (which it has nothing to do with).

Additionally, in an attempt to revert things for Canvas L2 support to see for themselves; now that we've created this cross-list, I've been unsuccessful "De-Cross-Listing this Section" out of this Course via the UI as an administrator.

N_YOUNG
Community Participant

Yep... i follow what you're saying about it not needing to exist in the old parent course, and needing to move to the new parent... leaving no trace of itself in the old one.

What i was saying, is that our experience is that you can do that operation in 1 step.... just an "active" row, and not needing to do an additional delete row beforehand.

Im inclined to think that your issue is going to be with the stickiness that you mentioned. We had issues with that a while back, but cleaned up and are not using that option at all anymore. It sounds like, off the top of my head, that you should be able to do a single "active" row in a SIS sections.csv file, but set the upload to "override stickiness = true".... and it should move it for you out of the old parent course and into the new one. At least... that's the way it's working for us. You might also need to "clear stickiness = true" on that same upload.... in order to prevent this from happening again.

Other things to check.....

Is the new parent course active, or is there anything special about it? Is it in a different sub-account, and are you using root credentials (that can manipulate everything in your canvas instance)?

matt_borja
Community Participant

I should also add that the "possible bug" (as you indicated), may very well be a bug in the delete action that's starting all this and until we can get our section De-Cross-Listed, I'm unable to (unless I find another course to test this with) just simply add the section to the new course without deleting it from the old one, per your recommendation. I'll let you know what I find out.

matt_borja
Community Participant

Yes, we're pretty much using root credentials (API credentials we have set up for our account). I may try the clear_sis_stickiness option to see if that helps reset things.

matt_borja
Community Participant

Just a quick update: We found another course today that has the same issue. I tried both [SIS delete + SIS] add as well as [SIS add only] per your recommendation and the section still gets added back to the original course, even with a completely different sis_course_id in the CSV.

N_YOUNG
Community Participant

yeah, totally sounds like a bug to me too.

stuart_ryan
Community Coach
Community Coach

Hi  @matt_borja ,

I am going through having a look at some of the early days in the Canvas Developers group, and checking in to see if older enquiries have been answered. I also noticed there hasn’t been any discussion on this question in quite some time.

I am wondering, were you ever able to resolve this (i.e. was it a bug that was later resolved)? I am hoping I can assume that it is well and truly resolved by now, but if not, please let us know and we can certainly have another look. Alternatively, if have some insights you may be able to share for others that would be awesome too!

I will mark this as assumed answered for the time being, however, by all means please let us know if you still have an outstanding question and we will take a peek!

Cheers,
Stuart