EMak
My feedback
8 results found
-
20 votes
An error occurred while saving the comment EMak
supported this idea
·
-
6 votesEMak
supported this idea
·
-
4 votesEMak
supported this idea
·
-
1 voteEMak
shared this idea
·
-
4 votesEMak
supported this idea
·
An error occurred while saving the comment EMak
commented
I'd like to have it so that when faculty submit a request as a book for reserves but actually only need a chapter, we'd catch it since it would print on the pull slip.
-
17 votes
An error occurred while saving the comment EMak
commented
I've got 60+ things stuck in my Link Checker queue. I've retryed them several times and they always work. They distort my ability to see if there is a new issue that has arisen. Thanks for considering this needed change.
EMak
supported this idea
·
-
12 votesEMak
supported this idea
·
-
2 votesEMak
supported this idea
·
An error occurred while saving the comment EMak
commented
Yes! I had a request from an Admin Assistant to be able to post items on a professor's Course Reserves account. I had an email confirmation from the professor that this person had permission to access their account. While I knew that I could import the course through the client it is important to be consistent and direct users to the web interface. Making exceptions creates confusion for the user regarding the workflow when they use the system in subsequent courses or semesters. This professor was going out of town and it would have been 2 weeks (per Admin Assistant) until they had the time to import the course. While it's a 2 minute task for those of us that use the system all the time, the professor did not have time to become reacquainted with the process.
At Wake Forest, we're transitioning to Canvas and allow instructors to activate courses through the web, based off of loads created by the Registrar.
We are experiencing an issue when instructors "cross list" courses in Canvas. The unique identifiers that associate the course with the users that are available via the loads are not able to predict the values and still allow access to students from both sections and the instructor. The custom_section_id has a different value for both of the initial courses at the beginning (for an example, these would be courses A and B and their respective ExternalCourseIDs would be 1234A and 9876B). The instructor enters either one of these courses and selects the option to merge. This creates and sends a comma-delimited value of the two courses' SIS IDs (1234A, 9876B) in the field that was pre-selected as the unique identifier in Ares. This creates a unique situation where a new course is created in Ares (with no items, so the instructor is concerned), but then the students have been pre-registered using the pre-existing unique identifiers, so they are still seeing the first two courses, not the merged ones, if they access Ares through the web, instead of going into the Canvas link. If they do use the Canvas link, it will successfully enroll them into the new course, with its comma-delimited unique identifier, but they're still enrolled in the initial courses and the loads will continue to enroll them in these courses and re-create the courses, even if we remove the initial ones, so the students and instructor are not confused by still seeing the pre-merge courses. We discovered an alternative value, the sis_id, also passes this unique identifier and will retain the value of the course that the instructor deems the "alpha" course between the merged courses. So, for our example, the unique identifiers will pass 1234A for users in course A and for the instructor, which means the instructor continues to see whatever items were in that course to begin with and students in course A can continue unaffected. The students in course B, however, now pass a different value in that field through Canvas, so the students in that course will only be enrolled into the updated course if they use the Canvas link (which we don't require they use, since we want to allow them direct web access). Even if they do go in and use the Canvas link, they'll continue to be simultaneously enrolled in both 1234A and 9876B, because the Registrar loads still pass the values, regardless of the action the instructor takes in Canvas. It gets worse: as the load jobs are used to automatically adjust enrollment for students as they add/drop, even if we forced students in course B to go and manually enroll through Canvas, by the next morning, they'll be removed, because the load is still passing enrollment as some students go to 1234A, some students go to 9876B, and the instructor as teaching both both. So students from course B who have been added by Canvas to course A, will be removed, because they don't appear as enrolled in the loads.