Page tree
Skip to end of metadata
Go to start of metadata
  • Process: suggestion from EDIT & CS IT → SG 20.5.2021 → edits → final version SG 10.6.
  • Technical implementation: planned together EDIT & CS IT summer 2021 → script CS IT → implementation either automatic or semi-automatic e.g. twice (or more times) a year; to be included in the version upgrade process

What phases could the lifecycle consist of?

We need to define the phases and also inform end-users about them and the conditions related to moving between the phases.

Course instance information

  1. course instance is "created"
    1. for a specific course instance, OR for exam needs, i.e for fixed-term needs, where the start and end dates are known.
    2. by request of the teacher responsible for the course
    3. (in the future, we have two types of instances:
      1. for degree program courses and exams which are combined with an "arviointikohde" in Sisu, and can include two types of students: A) students auto-enrolled from Sisu who get their grades registered in sisu AND B) manually enrolled MOOC students who do NOT get their grades registered in sisu
      2. for MOOCs and can only include one type of students: B) manually enrolled students who do NOT get their grades registered in sisu)
  2. course instance is "active"
    1. course start date is in the past
    2. course end date is in the future
  3. course instance is "available"
    1. course start or end date is at most 1 year in the past
    2. the course instance is publicly available and accessible for teachers and students
  4. course instance is "hidden"
    1. the instance could be hidden as part of creating a new instance for the same course → or should the instance be automatically hidden from students after 1year?
    2. it is hidden from public and students; teachers can still access
    3. teachers get a notification → this could also be part of creating new instance
  5. after the ongoing academic year + TWO previous academic years → at next service break
    1. teacher gets a notification ca 2 weeks before
    2. course instances will be deleted from production (plus.cs and tentit.cs). NOTE *) 

User-related information

  1. user logs in for the first time → the user profile is created. The user must be informed about the user profile life cycle before the profile is actually created. This is done on the login page.
  2. user provile is "active"
    1. e.g. user participates in courses, logs in regularly
  3. after the stage 5 in course contents life cycle, the user profiles are checked against conditions, and the user profile is deleted when it is not included in any course instance AND
    1. the Aalto accounts: account is expired
    2. Google and Haka accounts: the last login is over 12 months


Some data is duplicated because of the micro-service architecture:

  • Rubyric: user accounts, student submissions which use Rubyric, and their grades & feedback from teacher to students - does Rubyric log last logins separately? (does it log something else?)
  • MOOC-jutut: submitted feedback from students to teachers, teacher's response to the student, grading of the feedback (pass/fail)
  • Radar: submission similarity comparison data is stored for the submissions with a high similarity percentage

Acos server exercises may log the user's interactions in Acos exercises. The logs are stored in the Acos server, not A+.

  • No labels