onQ Support

onQ Support

Roles and Permissions

Note: There is a specific Accessibility role located under Administrative and Other Roles below for a staff member who works with a student with an accommodation.

Instructors, TAs and Students

Primary Instructor

  • Has full developing/grading permissions.
  • Cannot enrol Students
  • Can enrol Instructor and below.
  • Can impersonate Test Student.
  • Appears in Classlist as Primary Instructor.
  • Can email Classlist.

Instructor

  • Has full developing/grading permissions.
  • Can enrol below Instructor.
  • Can impersonate Test Student.
  • Appears in Classlist as Instructor.
  • Can email Classlist.

Instructor (No SN)

  • Same as Instructor role, but cannot see student numbers (org defined IDs).

Instructor NoEditing

  • Has full grading permissions, but no developing permissions.
  • Has no enrolment permissions.
  • Can impersonate Test Student.
  • Appears in Classlist as Instructor.
  • Can email Classlist.

Super Grader/Dev

  • Cascading (can see all sections/groups).
  • Has full developing/grading permissions.
  • Has no enrolment permissions.
  • Can impersonate Test Student.
  • Appears in Classlist as Grader/Dev (TA-S).
  • Can email Classlist.

Super Grader/Dev NCL

  • Same as Super Grader/Dev role, but does not appear in the Classlist.

Grader/Dev

  • Same as above role but not cascading (can only see a single section by default).
  • Can see all groups.
  • Appears in Classlist as Grader/Dev (TA)

Grader/Dev NCL

  • Same as Grader/Dev role, but does not appear in the Classlist.

Super Grader

  • Cascading (can see all sections and groups).
  • Has full grading permissions, but no developing permissions.
  • Has no enrolment permissions.
  • Can impersonate Test Student.
  • Appears in Classlist as Grader (TA-S).
  • Can email Classlist.

Grader

  • Same as above role but not cascading (can only see a single section by default).
  • Can see all groups.
  • Appears in Classlist as Grader (TA).

Grader NCL

  • Same as Grader role, but does not appear in the Classlist

Grader plus News

  • Same as Grader role, but also has permission to post News Items in the course. 

Super Developer

  • Cascading (can see all sections and groups).
  • Has full developing permissions, but no grading permissions.
  • Has no enrolment permissions.
  • Cannot see students in Classlist.
  • Appears in Classlist as Developer (TA-S).
  • Cannot email Classlist.

Developer

  • Same as Super Developer role, but is not cascading (can only see a single section by default).
  • Can see all groups.
  • Appears in Classlist as Developer (TA).

Student Role-Staff

  • Assign to Faculty/Staff to allow participation in a course, from a student’s perspective.
  • Can email Classlist. (Important: Student email visibility in the Classlist has been reviewed by the Privacy Officer)

Student

  • Default student role
  • Can email Classlist. (Important: Student email visibility in the Classlist has been reviewed by the Privacy Officer)

Test Student

  • Can be enrolled in a course by Admin, Sub Admin and Manager.
  • Can be impersonated in a course by: Administrator, Sub Administrator, Manager, Primary Instructor, Instructor, Instructor (No SN), Instructor NoEditing, Grader/Developer, and Grader
  • Can email Classlist. (Important: Student email visibility in the Classlist has been reviewed by the Privacy Officer)

Administrative and Other Roles

Administrator (Up to 2 per Faculty)

  • Cascading (Enrolment in all courses in a Faculty, Department or Program).
  • Has full developing/grading permissions.
  • Can enrol Faculty, Staff, Students, and Test Students.
  • Can enrol Manager and below.
  • Can Impersonate Faculty and Staff members.
  • Can impersonate Students – users enrolled in a course under the role of Student.
  • Does not appear in Classlist.
  • Can email Classlist.

Sub Administrator

  • Cascading (Enrolment in all courses in a Faculty, Department or Program).
  • Has full developing/grading permissions.
  • Can enrol Students.
  • Can enrol Manager and below.
  • Can impersonate Test Student.
  • Does not appear in Classlist.
  • Can email Classlist.

Manager

  • Cascading (Enrolment in all courses in a Faculty, Department or Program).
  • Has full developing/grading permissions.
  • Can enrol Test Students but not Students
  • Can enrol Primary Instructor and below.
  • Can impersonate Test Student.
  • Does not appear in Classlist.
  • Can email Classlist.

Accessibility

The Accessibility role should be applied to a Staff member who works with students needing Accommodations. 

  • Does not appear in the Classlist.
  •  Does not receive emails.
  •  Can access Inactive courses.
  • Can access modules set to ‘Draft’.
  • Can access Manage Files, at the Course Offering level.
  • Can download documents to work on outside of onQ.
  • Cannot access the Grade Book.
  • Cannot edit course content.

Visitor

  • Can be enrolled in a course by Primary Instructor or above. 
  • This is a ‘read-only’ role; user can see but not participate in course content, assignments, discussions, quizzes, etc.
  • Does not appear in Classlist.
  • Can only be un-enrolled in a course by an ITS Administrator.
  • Cannot email Classlist.
  • Note: Primary Instructors do not have permission to enrol students. If you wish to have a student enrolled in your course as a Visitor, please submit a ticket through the general ITS Help Form.

How to Request a Sub-Administrator or Administrator Role

Requesting the Sub Administrator Role

Users who require a Sub Administrator role must provide ITS with written consent from their Department Head. To request the role, please submit a ticket through the general ITS Help Form.

Requesting the Administrator Role

Once students and faculty/staff members have been enrolled into an onQ course and are using the system, there are times when a specific user may experience an issue within onQ that other users are not experiencing. In these cases, support staff may wish to "impersonate" this user to view exactly what he or she is seeing. For this reason, Administrators have been granted the "impersonate" permission within onQ.

Due to the level of permissions granted to an Administrator, onQ governance has decided that each faculty will only be permitted 1 or 2 onQ Administrators. To request a faculty Administrator, please follow these steps:

  1. Administrative staff should contact their Dean or Delegate to request the onQ Impersonate permission on their behalf.
  2. The Dean or Delegate should then request the permission be granted to the administrative staff member by submitting a request via the general ITS Help Form. In addition to requesting the permission,  the Dean or Delegate should also confirm that the staff member has signed the Queen's University "Confidentiality and Non-Disclosure Agreement - Staff" document.
  3. ITS will grant the staff member the appropriate permission to impersonate the user in question.
  4. ITS will contact the staff member to inform them of their elevated permission and to inform them of the standard impersonation procedure to be used.

Standard Impersonation Procedure

Due to the nature of the Impersonate feature, care must be taken when the functionality is used. The following procedure should be followed every time an Administrator impersonates a student or faculty/staff member in onQ:

  1. Authorization and Notice: A request for support that requires the impersonate feature constitutes permission. With this in mind, ITS and the CTL highly recommends written/email authorization from the user in advance. In extenuating circumstances, if an administrator feels they need to impersonate a user to help resolve an issue prior to receiving authorization (written, email, or verbal), they can do so. In these cases, the administrator will inform the user that they were impersonated after the fact.
  2. Documentation: Administrators must keep a log of when they've used the impersonate feature. This log should include, at a minimum, the following information for each time the impersonate feature was used:
    1. Date and time
    2. The name of the individual they impersonated
    3. The reason for impersonation
  3. Upon request, the Administrator must be prepared to send the log to ITS. ITS will perform audits from time to time. This will involve comparing Administrator logs with onQ logs.

Cascading Roles

Several of the roles in onQ are cascading, in that enrolment to the role at a departmental level will result in the user being automatically enrolled with the same role and permissions in all sub-units and course offerings beneath it. Someone in a cascading role is able to see all sections/groups within a course.

For instance, if a user is enrolled as Sub Administrator in the Engineering department, they will automatically become Sub Administrator for all sub-units (e.g., Chemical Engineering, Civil Engineering, etc.) and course offerings contained therein.

Cascading TA roles enrol the TA into all sections within a course, whereas non-cascading TA roles allow a TA to be enrolled to a specific section (the TA will see only that section).