Zamenhof / api

Public repo for issues and wiki.
0 stars 0 forks source link

Bug with absence statement #33

Closed kamilszczesny closed 6 years ago

kamilszczesny commented 6 years ago

I think there was a bug today with marking attendance and sending xAPI statement. It's about learner: 43041 (Yoshijima ) - 43041@Learning.com who was removed manually today morning (before class took place) from class: group 433, 21:00 Japan Time with Zan

Although student was removed and is not listed as one of students in this class (screen attached)

zrzut ekranu 2018-10-26 o 20 43 29 zrzut ekranu 2018-10-26 o 20 43 41

Mentioned student is not visible in the attendance list in Zamenhof UI.

But we got statement about this student being absent in the class around 12:30:36 GMT This means that teacher has seen this student while marking attendance although he was removed and is not assigned to this class when checking from admin account.

As result of this learner now is stuck in our system because we trat him as absent and we have to fix his state manually. Please investigate what is the reason of sending absence statement for this user.

patzamgit commented 6 years ago

We found the issue. The problem was from user end on the group create page. It was possible to:

  1. schedule a class,
  2. click the proceed button again
  3. schedule a second class at the same time.

Here what we did:

  1. after creating a class, the proceed button will be disabled. It will be re-enabled only if the user clicks on the reset button. EDIT: if the user clicks on the proceed button a second time, it will automatically reset.
  2. if, despite that, a lesson is created at the same time, the system will not register the second class.
  3. we added a script that will scan the past 100 registered classes for duplicates. If the same classID appear twice, we will immediately fix the issue manually an investigate for future improvements.
kamilszczesny commented 6 years ago

This bug happened again.

Situation was as follows: Learner (ext id: d8d20cd2-0e0c-4c39-8d11-bc7051bbff73) atsuka

Learner booked a class: Group 485 for 15th Nov 20:30 JPY Learner was visible in the Zamenhof interface

Learner changed his mind and requested rebooking (14th Nov) We did rebooking for different class As part of rebooking learner was un-confirmed from class 485 before class took place

Before learners new class took place we got absence from class group 485 on 15th 12:17 GMT This means that although learner was un-confirmed from this class Teacher could see him in students list and marked him as absent.

At the same time when we look at Attendance report in Zamenhof - this learner is not in students list: zrzut ekranu 2018-11-21 o 08 35 11 zrzut ekranu 2018-11-21 o 08 34 37

So above list should be what teacher sees when marking attendance, instead somehow teacher marked absence for student out of this list.

indrajitlahiri commented 6 years ago

I have fixed a small bug where now the teacher would not be able to visit the an un-confirmed class in the attendance window which was making the confusion.

I think we are having a general confusion in the way of the process of re-booking, we had the APIs developed in a defined manner and now its being operated i a different manner. Let me try to explain the difference I think we are having in the concepts of the operations.

The process re-book class is related with the zamenhof API named : rebook-class.php

The purpose is like this. Suppose Student A has a class booked on 15 Nov 16:00 hrs Group : 400, say that class id is 1000 (the actual dataase reference id which we deal with in all the apis - available class- boss class - rebook class etc.) Now student want to shift the class to another date/time slot on 16 Nov 20:00 hrs Group : 410 , say that class id 1200

Now this means the student exactly need to be shifted to that slot physically. We had the API rebook-class.php for that purpose. So that API would accept the old classid and new classid for this shifting. The parameters are like this for that api

key (your school identifier) classid (in the above example say its 1000 - the existing slot classid ) newclassid (in above example say its 1200 - new slot classid) studentid (your external id or zamenhof studentid) studentid_type (to say whether you are passing external id or zamenhof id)

Now what happens, the student package class date and group is just updated according to the new group class - so it would be updated from
15 Nov 16:00 hrs Group : 400 >> to >> 16 Nov 20:00 hrs Group : 410

So in the attendance report now that student will never be visible in earlier group report (of 400) and will appear in the new group report (of 410)

But In the situation you sent, there its not the case. The existing package is just unconfirmed for Group 485. And in addition he assigned in a new group probably 492. So he is staying in both groups - confirmed in 1 (492) and un-confirmed in 1 (485).


Now a different way to your problem you mentioned. I am leaving the above logic now there and trying to stay with the way you did that. The student was un-confirmed from Group 485 , so teacher will not see him anyways in the class and in absent report his record is not required to be marked as present or absent. He is insignificant in that group 485 now s the pack in NOT in confirmed state. He is ignored in the grade and attendance report. Which is logically correct. What you suggest in this view to change?

If you now view the attendance report on 20th Nov and follow for group 492, the student data would be visible there. Now there is another situation. Among 4 students of that group attendance was marked for 3 and this student (43002) was left unmarked (nether present or absent). So his data is showing in the "Unspecified Lessons" section and rest 3 are showing in "Confirmed Lessons" section.

kamilszczesny commented 6 years ago

You are describing process that we designed before we had any production learner in our system and it was based on assumptions.

Currently we know already that during rebooking process of selecting new class date can take even days :/ As a result in fact we are not using originally designed rebook method, because it doesn't fit our operations anymore.

Instead we are un-confirming learner from lesson in the interface manually, as Patrice explained once this should remove student from class.

And for the future - probably we will ask you to have API method just for removing students from class. Something like described here: https://www.evernote.com/l/ACiJ6DQXMHZB4ZCPyGVo8RSnkN9-4w4oaUU

indrajitlahiri commented 6 years ago

yes ok, the bug you mentioned is fixed in the attendance popup from the teacher panel. Unconfirmed student will not be visible there anymore and thus would not be in the xApi response.

nftlearning commented 6 years ago

Dear all, I want to make sure the issue is resolved successfully. Our logs show that in the week of 19-25 Nov we've received 11 no-show xapi statements from you - much more than usual (2-3 per week). Do you know (can you verify) which ones were sent as a mistake?