We just heard from a student who changed his name in the student information system but Ares still had the old name. (Note that ILLiad DID get updated, but not Ares.) I agree that user information should be updated by the loader.

This is a crucial update; we've had a number of students complain that the wrong name appears in Ares despite having gone through all the steps to update their name with the University.

From a diversity and inclusion perspective,a one-time import of a user record means that firstname/lastname doesnt get updated only once. Usually in these cases, the ID stays the same, but the related info around the username changes. This is especially problematic for any user who changes gender during the course of their stay with the university. +1 to being out of compliance with our identity source of truth.

It's quite important for us to keep Ares user records in sync with our systems of authority. Hopkins has started a policy to allow users to specify preferred name in our systems, and we are sending the users' preferred name through User.txt. This is especially important for trans users who have strong reasons for not wanting to use their old name. If Ares does not use the preferred name, we are out of compliance with university policy.

This is a required enhancement! We receive our user data from the registrar, and if users make updates to their records at this central point of contact, it should be overwritten on our side. It's come up a few times related to instructor first and last names, and creates an awkward situation when it involves someone who has undertaken a gender transition and here we are still using their old name from the first time the user record was created.

This would be really helpful for us. Our course and user load is designed to load the current and upcoming semester. Previously we had hard coded the dates for those semesters, but now we pull information in such a way that the definitions of "current and upcoming semester" change on a rolling basis. So it will load fall/spring, then spring/summer, then summer/fall. But usually the schedule is not finalized until after the roll over happens. So inevitably we have a fair number of people emailing us wondering why their courses are wrong. This enhancement would solve that problem.

There is a use case for this in frequently changing instructor assignments. At The New School, over 80% of our faculty are part-time and hired very close to the beginning of the course. we frequently have students drop and add to courses 2 or 3 weeks into the semester. Additionally, we have students who for various life events change their names. this is usually handled via SQL query. We would like our SRS update to be the single source of truth , so as membership of courses change, instructors change, and names change, all of this can be updated. It is frustrating having clerical staff manually update these fields which are automated in our ILS< but not in the reserves system itself.

Working with an Ares site who does CourseUser loads and has CourseCreationEnabled turned on, we found that the CourseUser load had added all of the WINTER2019 courses before the WINTER2019 entry had been added to the Semesters table in the Customization Manager. So since that semester hadn't been there, the load had tried to pick the best choice just based on the start and stop dates, but of course that was the wrong one. This required us to run several queries to isolate the right courses (luckily none had items yet) and edit them to have the correct semester. If the CourseUser load had the ability to overwrite the Semester field in the Courses table when it ran, they could just have run another course user load after adding the semester to the Semesters table and it would have fixed it.

This seems very much like the enhancement entitled "Course and user information comes from the load (overwrites Ares data)". UMUC voted on that and votes on this just in case.

The University of Maryland University College (UMUC) relies totally on course and user loads. Classes up to 2 semesters ahead are loaded, which results in some data being revised before the class is finally offered. Updating data like last names, email addresses, class enrollment, course name, i.e. every field, would greatly reduce the amount of out-of-date information now showing in records. This year, we forgot to update our semesters table, so all future classes were assigned the current and latest semester. It required a query(ies) to rectify the problem. It would be great if the load could fix situations like this, i.e. if we add a semester, then subsequent loads would correct the semester previously and incorrectly assigned to courses records.

I would like to have the option to update the Users table periodically, in order to update users' information. People's addresses change, their status may change, and it would be good to catch all these changes on a regular basis rather than expect that users will either notify us or change the information themselves.

We have a use case like this: User is created as UserType=User, but later the same user from the data file is changed to UserType=Instructor. This change is not reflected in the user record and the user could not be assigned to a course during the course and user loads process automatically.

There is also a request for the same to happen with course records.

This would need to be optional.