Skip navigation
All Places > Bridge in Schools > Blog
Weiwei Zhang

BridgeCon 2020 CFP open

Posted by Weiwei Zhang Dec 11, 2019

This is not a real blog post, but more of an information item just in case you didn't see the email announcing the call for proposal is now open for BridgeCon 2020. https://www.instructure.com/bridge/bridgecon

 

The call for proposal closes 1/17/2020. I actually couldn't find the submit for proposal area from the BridgeCon website. I only saw the link to the proposal submission form from the email I received. The link takes me to a google form. https://docs.google.com/forms/d/e/1FAIpQLSdN6YtwhN7AJtZtva5uEQ-aMhTWfVfxvuawrbcbMbsqQzmJGw/viewform?vc=0&c=0&w=1&mkt_tok=eyJpIjoiTURZeU1HVmlOREUxWVRsbSIsInQiOiJGaTRoTFBUVFZxbXJGYjJ4RmdPUzFQWklxUkdFejFyWkxiSU9GdWJpdG9HU0JtXC9nTXBUQmRwSzhcL085YUVuOWxEVzdEb2VFTWlFd0FQbmVJOThmeUdXdU1YeWF1K21aZzJSK1RxTWsybVBtN1wvdXRRQTdJcWVHblVNak9GZFgrYyJ9

 

It would be great to see more of us from higher ed presenting! 

Weiwei Zhang

BridgeCon 2019 Sessions

Posted by Weiwei Zhang Jul 15, 2019

Hello everyone,

 

This is not a typical blog post, but more of information sharing. You will find the BridgeCon 2019 session recordings here: https://www.instructure.com/bridge/bridgecon/2019/sessions 

 

Kate is working on getting the HE user group recordings. Will keep you all posted. 

 

Weiwei

In a perfect world, different configurations of smart groups can be created to meet all of our needs in training assignments. The reality might be a bit more complex than that—job classifications or titles often don’t have clear links to the required trainings that employees need, and this prompt us to look at a different direction—using the Learning Library for required trainings.

 

In the near future, we will launch first set of required trainings in the LL. Users will follow the instructions provided by the departments or supervisors, and take the trainings in the LL. Many of these trainings require due and expiration dates. This gives us two questions: 1) Can we set due and expiration dates for courses in the LL? And 2) What happens when the LL courses expire? Can users be auto re-enrolled?

 

The answer is: it’s complicated. I will try to describe my findings here, and I will break it down into a couple of different set up methods:

 

1) Let me start with a simple set up: putting a course in the LL, set the due, expiration date, and auto re-enroll. The result is, users do see the expiration date, but it doesn’t make a difference if a course is set as auto re-enroll or not. They both just sit in the completed course category.

2) This second setup is the interesting one: let’s put a program (called Cat) in the LL, set the due, expiration and auto re-enroll for the program. Then let’s put a course (called Sharma) in this program, but not set any due, expiration nor auto re-enroll for the course. Then we make the program available to learners in the LL, and don’t set any groups/learners for the course. Here is what happened:

 

Auto re-enroll program (Cat) in LL before expiration. I completed this on 5/21, the program expires on 5/23. 

 

Course (Sharma) in Cat before expiration. As you can see, it was a self-enrollment. 

 

Then, at 1:02am on 5/23, I received 2 notifications from Bridge. One says I was enrolled in a new course and one says I was enrolled in a new program. This tells me I was auto re-enrolled by the system at mid night. 

 

Then I went to Bridge. The Cat program is showing in my "Required" area, although course Sharma is not listed as an individual course under "Required.'

Then I looked at Sharma's learner page. My enrollment status has changed from Optional to Required. 

 

So, the conclusion seems to be auto re-enrollment does work in LL, only if we place courses in a program, and the program is set as auto re-enroll. My next step was to think what it means to us----should we use this feature for trainings that have expiration dates? The answer is, it depends. Let's look at the CSV exports: 

 

Here is the CSV export from the Cat program. Due and expiration dates are recorded. 

 

Here is the CSV export from the Sharma course. You can see it recorded my self-enrolled the first time, and the system enrolled me the second time. There is no due and expiration date for the first attempt (remember I didn't set this at the course level but only program level), but the course does talk to the program, and assigned me a due date for the second enrollment. 

 

Putting these two sheets together, I can get a pretty good picture of what's happening here. I think whether to use this setup would depend on the reporting and data tracking requirement, and maybe how savvy/comfortable you are with handing data in Excel. The spreadsheet may get messy and confusing after a few cycles of auto re-enrollment. What's more important, is that some settings are grandfathered in, so if there needs to be a setting change, some users would have one setting and others would be different.

 

I do think this can be useful and valuable in some cases though, and I hope this post will help answer some questions if you are also trying to piece the puzzles together.  

First, some background:

 

We are using the auto-csv upload option for population maintenance, and the log always shows errors of the form "Failed to set manager on user with uid …" because the manager listed in the CSV does not exist in Bridge.  This is expected, because we exclude some users from Bridge based on various attributes in our SIS, and some of those will inevitably be managers.  However, I can't just assume all the errors are of this nature and safe to ignore, so I've been tracking them every day to make sure they are not actual errors, and to identify any patterns that might be helpful or informative.  It is because I was tracking these 'errors' that I noticed something odd…

 

On 11/23/2018, I noticed a difference in the errors being reported - there were no errors on that day!  I knew that couldn't possibly be right, so I went back to the previous day and checked on all the users who had thrown an error at that time.  These were all users with managers who did not exist in bridge, so the attribute could not be updated.  Prior to 11/23, they all had an old manager listed in Bridge, but after that day they had no manager listed (a 'null' value), despite the fact that the csv information for those users had not changed.  So, two things happened: the manager went from an old value to 'null', and they stopped throwing errors despite the fact that the manager listed in the csv did not exist in bridge.

I continued tracking the affected users, and over time most of them were fixed in one of two ways: they were removed from the Bridge population, or the manager listed in the csv changed and that allowed them to be updated properly.  In this way, the number of affected users went from 12 to 3.  No explanation was found for this behavior.

 

The twist:

It happened again! 

 

We made a change to the logic that grabs user data from our SIS, which resulted in a large increase in our population.  When I checked the import logs the day after the change, it seemed normal at first glance, with about 50% more manager-related errors being reported.  However, the last line of the import log said 'Failed to complete import', and at least one user had a mismatch in the manager information between Bridge and the csv.  Additionally, 10 users had a 'null' value for the manager in Bridge, and a manager in the csv that was not in Bridge.  These users did throw the expected errors in the log, so at first I did not see any connection between this and the other situation from 11/23.

 

We contacted support regarding the failure message in the log and the manager mismatch, and we were informed that the import had timed out so user data was not updated properly.  The next day, the import ran to completion and the mismatched data was corrected.  However, at that point the 10 users mentioned above no longer threw any errors in the log, even though the csv data had not changed.  They still had a 'null' value for manager, and the managers in the csv did not exist in Bridge.  This appears to be the same situation, which makes me think the original issue was also caused by a timeout which went undetected.

 

The implication seems to be that a timeout during the import can lock some users into a weird state, where they should be throwing errors but don't.  This seems unlikely to result in any serious problems, but it is a behavior that is interesting and worth noting.

Hey everyone! Kate Toothman has been hard at work getting all the pieces in place for this little corner of the Bridge Commuity we call Bridge in Schools. It is a place for any Bridge user who works for an educational organization, or is interested in those use cases, to share tips, tricks, success, and challenges, and to network with other Bridge in Schools users.

 

BIG thank you goes out to Weiwei Zhang for volunteering to help everyone in this group get started and find what they are looking for.

 

Stay tuned. There is so much to come!