[ARCHIVED] Canvas/Banner integration not recognizing returning students

Jump to solution
mmitchell
Community Contributor

We've recently seen a rise in the number of student accounts we've had to manually create in Canvas due to our Canvas/Banner connection not recognizing returning students.

These students have a few things in common:

  • Attended back when we didn't have Banner
  • Have no new application info (SAAADMS)
  • Have no new SGASTDN info (curricula)
  • Updated SPAIDEN info
  • Have registered for classes

When I run a manual push (ICGORODM or ICGORLDI), these students appear in the xml export but do not come over to Canvas.

Have any of you run into this issue before? Anyone have any ideas as to how I might troubleshoot the issue?

Manually creating students is not my idea of a good time.

Thanks for any info you have!

Mike

Labels (2)
1 Solution
mmitchell
Community Contributor
Author

Thanks to CSM Kelly Farr, it looks like it's coming from this Canvas update back in January:

https://community.canvaslms.com/docs/DOC-8731-canvas-production-release-notes-2017-01-07#jive_conten... 

"Even though CAS/LDAP authentication is in place, CanvasAuth is still present and still stores passwords (even if they are never used).  When Banner attempts to create new accounts for the users affected by this issue, it's attempting to pass Passwords for CanvasAuth into the Canvas database.  Since these passwords do not meet the 8-Character length requirement, Canvas then must reject the entire user creation request.

I've reached out to one of our SIS/Banner specialists here at Instructure, and they shared these instructions on their understanding of how you can configure Banner to avoid this going forward.
When selecting from the student table (SGBSTDN) or Instructor/Employee table (SIBINST/PEBEMPL).
If they want to stop sending passwords, they are called pins in Banner, so they need to exclude selecting from the (GOBTPAC_PIN) table.
If they need to update those pins/passwords if they're not long enough.
Authorized administrative users can mass-assign PINs for a group of persons by using
the PIN Creation Process (GURTPAC).
When mass-assigning, they then need to make sure that they are choosing a field that is longer than 8 characters.  That may mean concating (combing) multiple values from the Student/Teacher/Staff table to ensure this. So maybe it could be DOB+ID_number.
PIN preferences that set a default PIN are also controlled in the (GUAPPRF) record."
I'm going to send this off to our Banner dba and see if we can configure it.

View solution in original post