Attendance app integration

Registered by Tom Hoffman

Blueprint information

Status:
Started
Approver:
Frances Bowen Day
Priority:
High
Drafter:
SIELibre-Ark Collaboration
Direction:
Needs approval
Assignee:
Douglas Cerna
Definition:
Approved
Series goal:
Accepted for 2.10
Implementation:
Beta Available
Milestone target:
milestone icon phase-1
Started by
Tom Hoffman

Related branches

Sprints

Whiteboard

Our estimate for this is 40 hours (1 week).

0) In all situations where data between the two conflicts, most recent change wins.

1) We need to pull all student records from the API and check for updates to enrollment and demographics.
1a) Ideally this is scheduled via the web interface. If it is too bandwidth hungry to do daily, then weekly, etc.
1b) If SchoolTool has the more recent change, push it to Journey.

2) Changes to people (enrollment and demographics) in SchoolTool should be pushed at time of change.
2a) I don't think we should bother marking these as successfully synced or not, because I think we'll just have to run big sync checks pretty regularly either way.

3) SchoolTool attendance changes should be pushed at the time of change to Journey.

4) We will periodically pull daily (hourly?) attendance changes from Journey, exactly how to do this depends on the API.
4b) Again, if ST has the more recent data then, we'll try to push.

QUESTIONS:
- The attendance codes in the app don't match the ones we've been given for Rising in SchoolTool. These need to match or we're going to lose data & have inconsistencies.
- Is a study group in the app a stream or a section?
- how do you identify a student uniquely in the app with an attribute set by the user?

Fran: On the questions
1) Journey was going to change the attendance codes right
2) Study group is a stream not a subject section
3) We need to give the user IDs that are in school tool to the students in the app - again journey said they would create this column

On the conflict point (0) I spoke to Rising about this in Sierra Leone and I think let's say that changes can only be made from school tool, not the app. So once data has been submitted for a day of attendance, changes have to be made on the system. I think this should reduce the complexity right?

Tom: It helps. Should we plan to just download the previous day's attendance in the middle of the night each day? Can we assume the changes to personal info will also be made on the SchoolTool side?

Fran: could this happen earlier than that? I would suggest that it tries to sync at 11am each day (local time) as the teachers will take the register by 9.30/10am. And it would sync whatever updates are there (e.g. it might be for 1 day or 3 days).

Tom: Yeah, it could be at 11AM.

How will this sync actually happen? Is there a way to manually push the update as well? i.e. teacher pushes the data to the system once the register is complete (and at a time when they have 3G connection)

Tom: You cannot make the Journey App push to SchoolTool without making changes (that is, new code) to the Journey app (and SchoolTool).

Fran: so to summarise this would be 40 hours and would:
* Pull attendance registers from the app to the system for Present and Absent codes - Absent would be set to Absent unknown
* Changes to student attendance codes would be done through the system only
* Students are linked by the student ID (which has been added into the journey app)
* Student details are synced (e.g. any new students, changes to class registers etc) from school tool main system to app

Question: how does the sync work exactly - I am a bit worried that if schooltool tries to pull the data at a specific time (e.g. 11am) and the 3G coverage is poor then it won't necessarily work... Can we have a auto-pull daily at 11am (which would pull as many attendance registers as haven't yet been uploaded to the system) but also the option to manually push the register at a time when the 3G coverage is working as a back up to this? I guess this could also be a manual pull from school tool rather than a push from the mobile app if that is easier but we do need a manual back up I think...

Tom:
The bullet points look right. Regarding sync, we should be able to set our task scheduler to re-try the sync periodically until it succeeds. We'll need a task/sync management page which will confirm if the sync has or hasn't been done successfully for a given day, and probably a manual override to re-try it if it has completely failed for whatever reason (which in theory shouldn't happen...).

Fran: sounds good Tom. Thanks. Am just waiting for final confirmation from Rising before I hit approve.

(?)

Work Items

Work items:
Study API docs: TODO

This blueprint contains Public information 
Everyone can see this information.

Subscribers

No subscribers.