Generic recruiter: end-point customisation: 5pts
See original GitHub issueRequirements/objectives
Related to #2464 As part of the generic recruiter, we want to be able to do the following:
- Have a customizable experiment method that generates
exit_info
about the participant. Thisexit_info
is saved in theParticipant
object and might contain for example a randomly generated code that is used to validate their session with an external recruitment service. - Have a custom completion page (specified as an HTML template) where we might for example display this randomly generated code to the participant, or provide a link for the participant that will take them back to the external recruitment service.
Pre-implementation Notes
How Does this Work Now?
MTurk Recruiter
[N.B. The options described below that use the participant_task_completed()
callback assume the completion of https://github.com/Dallinger/Dallinger/pull/2548.]
- The /worker_complete route will call the Experiment with the participant via
exp.participant_task_completed(participant)
. This is probably the first opportunity to do something. Unlike thesubmission_successful()
calls described below, this one is synchronous. - When the MTurkRecruiter’s SNS notification route is called, the Experiment’s
submission_successful()
method will be called with the Participant:self.experiment.submission_successful(participant=self.participant)
- This
self.experiment.submission_successful(participant=self.participant)
will also occur if the heroku clock is running and maximum experiment duration has been exceeded and the Participant’s status is “Submitted”
Other (CLI) recruiter(s)
- The /worker_complete route will call the Experiment with the participant via
exp.participant_task_completed(participant)
. This is probably the first opportunity to do something. Unlike thesubmission_successful()
calls described below, this one is synchronous. - The /worker_complete route will enqueue a task which triggers a call to the Experiment’s
submission_successful()
method with the Participant:self.experiment.submission_successful(participant=self.participant)
Regardless of recruiter, the participant_task_completed()
call will happen synchronously when the experiment is completed, but as things are implemented currently, before Participant end_time
is assigned, status
is set to “Submitted”, and data checks are preformed. The async submission_successful()
call happens after these updates are applied, but still before the Participant is redirected to the /ad page.
When should the Experiment assign exit_info
?
It seems like either of these existing callback points would work. @pmcharrison Do you have a preference? I’m also not attached to where and how we orchestrate data checking, bonuses, participant status updates, etc, as there’s a lot of possibly needless chatter back and forth between the executing worker_function and various Experiment callbacks. That said, the easy path would probably still be to leave all of this as-is.
Since the submission_successful()
call happens after data check, etc., I’m inclined to use that callback. It also has the fact that the default implementation is currently empty going for it:
def submission_successful(self, participant):
"""Run when a participant submits successfully."""
pass
We could either add the exit_info
assignment directly to this method, or we could have it call a new, separate, special-purpose method as you originally suggested (I think this is probably clearer overall, despite the added call).
Issue Analytics
- State:
- Created 3 years ago
- Comments:9
Good question - I think it can be left empty by default.
On Thu, 11 Feb 2021 at 6:45 pm, Jesse Snyder notifications@github.com wrote:
This branch has the same issue as in #2599 as a results the information in the entry point is not saved and is “empty” at the end-point.