Course and user information comes from the load (overwrites Ares data)
Course and user loads - changes to the user and course information loaded would overwrite the user and course information in the Ares database. There would be an option to prevent web users from editing their own user info and course info. Course and user info could be edited (overridden) in the staff client, but subsequent edits of the course and user info would not carry over after the client edits were made.
Allen Jones commented
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.
Angela Mott commented
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.
Peter Burslem commented
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.
Peter Burslem commented
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.
Lingling Jiang commented
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.
Anne Marie Lyons commented
There is also a request for the same to happen with course records.
Genie Powell commented
This would need to be optional.