Following from #268, we added an endpoint to check in hackers, but we still need to be able to check in non-hackers. In conjunction with #322 as part of #318, we'll assume for now the status of non-hackers will be updated to CONFIRMED or ATTENDING (exact TBD), so the logic is almost the same as for non-hackers. The only additional check we should need to make is that the user role is not empty.
Repurpose participant_manager.check_in_applicant to allow checking in non-hackers.
Make sure the user's role is not empty during the database query
Use the same existing status check (ATTENDING or CONFIRMED)
Following from #268, we added an endpoint to check in hackers, but we still need to be able to check in non-hackers. In conjunction with #322 as part of #318, we'll assume for now the status of non-hackers will be updated to
CONFIRMEDorATTENDING(exact TBD), so the logic is almost the same as for non-hackers. The only additional check we should need to make is that the user role is not empty.participant_manager.check_in_applicantto allow checking in non-hackers.ATTENDINGorCONFIRMED)