UPchieve/web

Volunteer scheduling system audit

Closed this issue · 5 comments

ti2ger92 commented

Carefully review the way we initialize & modify the volunteer availability property on the server

Sometimes, the user availability hours disappear, while the days remain. This causes the frontend to break and prevents the volunteer from updating their schedule.

No clear steps to reproduce at the moment. It's mysterious, which is why this requires a careful audit.

The following steps reproduce the issue:

  1. Download the HTTP Request Blocker Chrome extension.
  2. Add to the blacklist the URL of the /api/calendar/get endpoint for the server on which you want to test. (i.e. http://<server_name_or_ip>:3000/api/calendar/get.)
  3. Log into the server as a volunteer and navigate to the "Schedule" page.
  4. Click the "Save" button (even though you don't see any hours).
  5. Unblock the API endpoint, then refresh the page to see that the hours have now disappeared while the days remain. (Note: To unblock the API endpoint you need to click "Save" after removing the URL from the list.)

Notes:

  • This seems to mainly occur with new volunteers
  • It only seems to happen with ~10% of volunteers
jkeat commented

Note: this is definitely still an issue as of 12/4/19!

dmnisson commented

I'm not sure if this is the main cause of this issue, but if I comment out the code in the fetchData method of the CalendarView to prevent it from sending the request to obtain availability data and then click the "Save" button on the CalendarView, the updateAvailability method is called with an empty availability object, causing the user's availability data on the server to be erased with hasSchedule still set to true; subsequent getAvailability calls then see hasSchedule and do not re-initialize the data, and the issue appears even when I restore the fetchData code. A situation like this could actually occur if a temporary network glitch causes the call to /api/calendar/get to fail, since the Promise in the fetchData method has no error handler. I'm not sure how many users would click the Save button if they don't see their hours, though.

dmnisson commented

The issue also appears if I use a REST client to POST to /api/calendar/save with a valid userid and an empty availability object, as would happen if only the /api/calendar/get call were to fail.

dmnisson commented

Steps to reproduce:

  1. Download the HTTP Request Blocker Chrome extension.
  2. Add to the blacklist the URL of the /api/calendar/get endpoint for the server on which you want to test. (i.e. http://<server_name_or_ip>:3000/api/calendar/get.)
  3. Log into the server as a volunteer and navigate to the "Schedule" page.
  4. Click the "Save" button (even though you don't see any hours).
  5. Unblock the API endpoint, then refresh the page to see that the hours have now disappeared while the days remain. (Note: To unblock the API endpoint you need to click "Save" after removing the URL from the list.)

The issue occurs only if the request to /api/calendar/get fails but other requests succeed, which would explain why the issue appears to occur randomly and has been so difficult to reproduce.