New “database” version of Isotoxin engine

Roger Kreitman
Mantissa Ltd

28 May 2008

Change log

28/05/2008Add fields to student/user data structures on page 7

TUE 24 June 08

Hi Roger,1. login screen must be HTML page or can be flash (6 or can be higher ????)2. i don't think that solution to have separate databases for each client is good solution (page 4 in your document). I think that solution to have one database is better also for backups database on another server.3. do you want to convert all your existing courses and user data into new system ?4. I think that the way to have SOME data as static XML or dat or swf files is good. We need it only for user organize XML file, but every user organize file for any course will be unique. For example internal course ID will be 23 and user's organize file will be 23_organize.dat.5. what did you mean on page 6 course configuration - the course manifest. What information you need to change ?6. in course configuration you will need also functionality to add/remove course activate/deactivate course.so this is my questions. I will try to find way to do not change editor, just viewer.Definitions

Customer. An organisation for whom Mantissa provides one or more manifests of courseware. Examples: Trafigura, Barclays, Mitsubishi

Portfolio. A body of course data comprising units and pages in a hierarchical folder structure., plus associated graphics data structures. Could be all the material that Mantissa has developed on a topic such as trade finance. NB different manifests/courses can access a single portfolio.
Currently represented by the DATA and LIBRARY folders and sub-folders, with an ITEM<XX> name for each unit, and subfolders for graphics.

Manifest. A syllabus or course that is specified by an ORGANIZE.DAT file. Typically this will be a subset of a portfolio.

Course. Synonym for manifest. Users are assigned to courses – login names and passwords are created for them.

User. Synonym for student. Belongs to a customer. User accesses one or more courses using a username and a password.

Manager. Person, belongs to a customer, who has the ability to create students, assign students to courses/manifests, view student results etc. The manager can only view results for students the students that he/she owns.
NB A manager is optional. Where there is no manager, an administrator or super-user can perform all operations on all students.

Super-user. Relates to a specific customer. Canperform all operations on that customer’s records (create students etc.) There can be more than one super-user for a customer.

Notify person. Optional. For each student, a person who is notified by email when the student is assigned to a course. Could be the manager, or another person.

General aims for the new version.

  1. We need an activity log of events such as “start a unit”, “complete a unit”, “pass a test”,” fail a test”, so that reports can be generated of activity over a period of time. Example: list of students who started and/or completed units between a specified starting date and end-date.
  2. We must replace the file-based user data structure with a database that has a “user” entity that can be applied to multiple courses. (Create user profile once, then grant the user access to courses.)
    Also to include user classification tags such as region, department. These will be used for filtering reports.
    NB we need to continue to use the existing file-based student storage mechanism for courses that we export for stand-alone use or use on LANs.
  1. Common access to the portfolio core resources (pages, library) by different customers who may have:
  • different organize.xml manifests (subsets of the total portfolio)
  • different screen furniture (lesson headers and footers)
  • different login screen and menu screen backgrounds
  • different toolkits

The aim is to simplify updates of the core portfolio – a single set of files will be maintained and shared by different customers, whose views of it will be determined by their manifests, toolkits etc

  1. A reliable way of maintaining reasonably up-to-date student records on a secondary website, which will come into action using a failover mechanism in the event of failure of the primary website. (We already have the failover mechanism.)
    We will also need to resynchronise the primary student record when the primary server comes back online.

Outline solution.

Use MySQL for the student activity log and for the student database – items 1 and 2 above. My current thinking is that there should be a separate set of databases for each customer, for flexibility.

Item 3. A configuration table for each customer, specifying the data source for the lesson pages, the toolkit, the menu layouts etc.

Item 4. To be discussed. In general terms, the requirement would seem to be for a background process using FTP or similar, using flags within the database to indicate which records on the primary server have been modified since the last update operation.

Data structures for courses

Student static data

Student progress data – status and score on each unit (where applicable); time spent on the unit.
Records of events generated by the Rules.xml system, e.g. once-only sending of emails.

The logged-in flag or an equivalent. NB this flag must time-out after a period of inactivity by the student. At the moment it just toggles on and off, and students fail to log out correctly, so it stays set.

Student ‘activity event’ data, e.g. records that an email delivery script has run.

The activity log

Management system functions

Student/user

  • Create a new student record
  • Edit an existing student record
  • Delete a student record
  • Assign a student to a course, including sending notification email to the student and the student’s manager or notify-person
  • Batch assignment of students to a course, using a spreadsheet (CSV format) as the data input
  • Batch process fort the leavers list. Batch modification of student status, using a CSV format spreadsheet as the data input (change employment status from True to False.)
  • Show results for specified students – HTML “table” format and CSV spreadsheet format
  • Activity reports for a specified range of dates, using activity log. HMTL “table” format and CSV spreadsheet format.

Regions and department.

(Regions and departments are part of the student record, and will be selected from drop-down lists when new students are created.)

  • Add a region or department to the list
  • Delete a region or department from the list

Managers

  • (Performed by super-user) Create a manager
  • (Performed by super-user) Edit a manager record
  • (Performed by super-user) Delete a manager
  • Manager login screen

Course configuration (only used by Mantissa)

This record is at the “Customer” level, and specifies:

  • The customer
  • The course manifest
  • The location of course data (pages, library)
  • The toolkit, screen furniture, login and menu pages etc

Customer page (only used by Mantissa)

  • Customer name
  • Customer ID code (used as internal database key)
  • Contact person
  • Phone
  • Email
  • Use managers? (True/false)
  • Use notify-persons? (True/false)

Super-user page (only used by Mantissa)

  • Customer ID
  • Name
  • Login
  • Password

Data structures

Student/user

A student will be represented by:

  • Firstname, middle name and last name
  • Customer
  • Login name and password
  • Email address
  • Region
  • Department
  • Manager (optional)
  • Notify-person (optional) – name, email address
  • Start date (optional) – (added June 08)
  • ‘Active’ flag (true/false) (optional) - – (added June 08)

Notes:

The region and department tables are specific to a given customer

The “customer” record will have a Boolean flag for “Use manager”. Where this is true, a student must have a manager, who can view records, create further students etc. Where this is false, there will be no managers and the superusers perform all operations.

The notify-person record will just be a name and an email address. It will usually be created using a spreadsheet as the input to a batch-mode operation.

Start date and ‘active’ flag – required by a specific customer (Trafigura)

Manager

A manager will be represented by:

  • Firstname, middle name and last name
  • Customer
  • Login name and password
  • Email address
  • Region (optional)
  • Department (optional)

The activity log – see item 1 of “General aims for the new version”

There will be a separate log for each customer.

The events that the log will record:

  • Login (LOGIN)
  • Logout (LOGOUT)
  • Launch a unit (START <unitID>)
  • Complete a for-credit unit, with an outcome “pass” (PASS)
  • Complete a for-credit unit with an outcome “fail” (FAIL)
  • Complete a not-for-credit unit, with an outcome “completed” (COMPLETE)
  • Exit a unit before completion (EXIT)
  • Move to next page (*) (PAGE)

The event record will contain:

  • User login name
  • Date
  • Time
  • Event ID, e.g. LOGIN, START, PASS
  • Data if required, e.g. score for a for-credit unit, page number

Notes: I am not sure whether we need to record the event “Move to next page”. It will greatly increase the size of the database and I am concerned about performance issues. Can the recording of this event be controlled by a switch?

There should also be an event when the session ends through a timeout (no student activity)

Other issues to be addressed.

1)Organisation-specific pages. This is a way of adding new content to a course on a per-customer basis. Typical use will be a description on an organisation’s internal practice or procedure. These can be thought of as notepad entries similar to the user-specific notepads in the toolkit – but all students for a customer get to see them.

2)User sessions must close themselves after a period of inactivity – replace current toggle for logged in/not logged in.

3)The mechanism for maintaining student activity times – both on a per-unit basis and for the course as a whole. Check that this is working.

4)A way of seeing who are the active on-line users

5)A way of passing username and password directly into engine as parameters, bypassing login screen.

6)A hangover from last piece of work. Get the old (file-based) student records to work correctly in standalone mode. These were not tested during the last piece of work (changing all DAT files to SWF files.)

Michal Mitrik: new database structure for courseware engine1