- 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
- course instance is "created"
- for a specific course instance, OR for exam needs, i.e for fixed-term needs, where the start and end dates are known.
- by request of the teacher responsible for the course
- (in the future, we have two types of instances:
- 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
- for MOOCs and can only include one type of students: B) manually enrolled students who do NOT get their grades registered in sisu)
- course instance is "active"
- course start date is in the past
- course end date is in the future
- course instance is "available"
- course start or end date is at most 1 year in the past
- the course instance is publicly available and accessible for teachers and students
- course instance is "hidden"
- 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?
- it is hidden from public and students; teachers can still access
- teachers get a notification → this could also be part of creating new instance
- after the ongoing academic year + TWO previous academic years → at next service break
- teacher gets a notification ca 2 weeks before
- course instances will be deleted from production (plus.cs and tentit.cs). NOTE *)
- 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.
- user provile is "active"
- e.g. user participates in courses, logs in regularly
- 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
- the Aalto accounts: account is expired
- 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+.