Sessions
From Dokeos
Contents
|
Overview
The concept of sessions has been added in Dokeos 1.8 as a way to put a time limit to the usage of a course by a student. Previously, a student would be manually removed from a course at the end of his classes, or automatically by an external system (but this implied such external system governing the subscriptions inside Dokeos).
During the implementation the idea of Sessions improved from a simple time limit to a full entity with its own administrator, its own set of courses and its own set of teacher per course (as well as the initial start and end date).
Within two years of progressive adoption, the sessions system had become something very important for some institutions as it allowed them to replicate the university cycle of one year, six months or even less in some cases. It also got a lot of attention on the aspect of being possible to differentiate a course teacher (out of session context) from a course tutor or assistant (inside a session context). The course teacher would be allowed to modify the course as a common base, and the course tutors would only be allowed to interact with the students on top of this. This was later modified to allow tutors to add their own content on top of the static course.
The following schema tries to explain the different components of the session process
Concepts
Participants
Sessions admin
The sessions admin is a user that has the ability to manage the sessions. He has limited access to the admin interface (only to define sessions and subscribe users). A sessions admin must be defined as such during the user registration process by a platform administrator, or has to be modified by a platform administrator later on to get this title (and the corresponding set of permissions).
Session tutor
A session tutor is a normal teacher that is granted a special title for one specific session. This will also be the tutor defined for all courses in the session by default (the sessions admin can then change this assignation later on in the session edition screen).
This tutor can access all courses in the session as the normal tutors, but cannot assign tutors to specific courses (this is done by the sessions admin).
Session-course tutor
A session-course tutor is a teacher designated as a tutor for a specific course inside a specific session. This tutor will have the right to edit the course tools in ways limited to his session. That is, all modifications he might undertake in a course will always remain purely inside the current session.
Human Resources Director
A HR Manager, or director, is designated as such by the platform administrator during the user registration, or later on during the user edition through the platform admin panel. This user has the permissions to follow specific users. This is an "observator" role, which is limited to follow the progress of users that has been assigned to him. This user cannot update courses (not even in a session), but he is able to export reports of progress, and has specific interfaces that allows him to get a quick overview of the progress of whom he is following.
In the context of a primary school, this role can be renamed (see language files or language translation feature) and enable access by the children's parents. This is an ideal "hack".
Sessions and the course tools
Because it was born from the idea of having one course teacher and several course tutors, the first implementation of sessions made it only possible for tutors to participate inside the course (and through the session) by using the "interaction" tools (the tools that allow direct interaction with the students). All "content creation" tools would be left to a possible modification by the only course teacher, but could be "used" by all.
This concept is currently under extension, and the tutor will be able, in Dokeos 1.8.6.2, to add documents and other content creation tools elements of its own "on top" of the base course elements. Tutors will also be able, in 1.8.6.2, to hide documents from the base course from their students (but they will not be able to delete them).
Sessions and classes
The "class" feature was originally designed as a way to group students into one entity that could later be assigned to one or several courses instead of assigning each and every user to the courses. As such, it allowed a teacher to replicate the idea of a "class" of students, who would be following the same courses through an academical year.
Sessions came as a feature that extended and duplicated the class feature, which deprecated it, in a way. With a session, however, we introduced a new level of complexity. One had to understand what a session was, how it could be used and how to control it, which meant that many users would not accept the change straight away. This, together with the Dokeos philosophy of keeping things simple, made us provide this feature in Dokeos 1.8.0 (May 2007) as a non-default feature that you had to enable before you could use it. When enabling it, it would automatically hide the class feature, to avoid confusion in combining both features. We have no clear track of when exactly the Sessions feature was made a default option, but it was between 1.8.0 (May 2007) and 1.8.4 (September 2007). The move was made because most customers of the Dokeos company were asking for a similar feature, as well as public calls for tender, and didn't consider it because it was a "hidden" feature.
Sessions as academic cycles
One possible use of the sessions, and actually its initial objective, is to use it as an academic cycle. Meaning that a group of students can follow a group of courses taken in charge by various tutors through an academical year or semester.
Sessions as private sessions
Another possible use is for private or online schools that offer private tutorials, in which one student registers and then has access to a course only from one date to another (depending on his subscription). In this case, the session is created with only one user in it. It is a bit more difficult to manage for the sessions admin, because there will be a lot of sessions, and it also prevents the student to get in contact with other students of this course, but it fills the need of time limits and independent tracking.
Sessions as collaborative entities
A session can also be used (although less attractive in this case) to provide a time-limited shared space for students, so that they can play around in a course space for a while, then the session can be archived...
Sessions history
Dokeos 1.8.6.2 should provide a way to recover the history of past sessions, and enable the possibility (this has to be enabled) to get access to them in read-only mode. This could enable students to come back to the platform years later and consult whatever they had access to in the past.
Multiple tutors per course
In the case that one course is taught by one theory tutor and one practices tutor, you need to define 2 tutors (or more) per course inside a session. This will be possible in Dokeos 1.8.6.2
Exclusion of one course
If a student has to pass the same academic cycle again, but has passed 2 out of his 6 courses, you can restrict his access in the current session to only the 4 failed courses (only available from 1.8.6.2).
Development information
Sessions in the Dokeos code
You will find the sessions management code in
- main/inc/lib/sessionmanager.lib.php
- main/admin/ (series of scripts to register sessions)
- main/inc/local.inc.php (to define which is the current session)
Sessions in the database
The database tables used for the sessions are session, session_rel_course, session_rel_course_rel_user, and from 1.8.6.2 on, session_category
Note that the idea of defining documents per session lead to considerable problems in the documents structure (which is directory-based), so directories named by the session ID have been added inside the course directories to deal with the problem (this problem should disappear in Dokeos 2.0 as documents are linked to users, not courses).
