Rejecting all interviews from one Interviewer

What would the process be for rejecting all interviews from a certain user using the API?

From the API docs it looks like it’s a multi-step process but I’m not sure what the most efficient path would be.

I would use the /api/v1/interviews endpoint to get the full list of interviews on the server. Unfortunately you cannot filter by respondibleID or name as a parameter of the query so then you’d have to do it with the data you get back from the API to get all the interview IDs associated with the user. And then feed those interview IDs forward to in your PATCH query for one of the reject endpoints.

@arthurshaw2002 may have a more efficient way since he is much more experienced with rejecting interviews using the API than me.

@macuata and @l2nguyen, I agree: this is a multi-step process.

I see an alternate path to Lena’s:

  • Download the data
  • Use the interview__actions data to identify all interviews for which the interviewer is responsible*
  • Collect the interview__id for all of the above
  • Merge by interview__id with the main data file
  • Keep observations where the interview__status allows you to reject (i.e., Completed and ApprovedBySupervisor
  • Create a file for for each status
  • Use the PATCH /api/v1/interviews/{id}/reject endpoint to reject those interviews sitting with the supervisor (i.e., Completed)
  • Use the PATCH /api/v1/interviews/{id}/hqreject endpoint to reject those sitting with headquarters (i.e., ApprovedBySupervisor).

I think Lena’s solution is more direct and efficient, but I don’t quite see how implement it. Here are the problems I see:

  • The GET /api/v1/interviews endpoint returns all interviews on the server and both the name and ID of the user responsible. If the person responsible is an interviewer, the interviewer will not be in a rejectable status. If the person responsible is not the interviewer, you’ll need to know how that person relates to the interviewer. If HQ, all is good. If supervisor, you need to know who the interviewer’s supervisor is–ideally, programmatically.
  • There is, so far as I can tell, no API endpoint that returns the list of interviewers and their IDs–or, even better, the name and ID of their supervisor. To construct this information, one needs to fetch the list of supervisors via GET /api/v1/supervisors and then the list of interviewers for each supervisor via GET /api/v1/supervisors/{supervisorId}/interviewers. Alternatively, one could construct this via the interview__actions data, but that will result in a potentially incomplete frame if no interviewer or supervisor is present in that file.

Maybe Lena or others see how to address these issues (if indeed these are issues).

1 Like

I think my suggested solution was oversimplifying it since I forgot the first issue that @arthurshaw2002 mentioned about how to link the user currently responsible for it to the interviewer. I think his solution might be the most straight forward way to get there.

As for getting the list of interviewers and their supervisors, there is indeed no endpoint to get the list of interviewers and their corresponding IDs as confirmed by Sergiy in this thread.
I usually do get that data in the HQ UI by exporting the list of interviewers. However, this method is not ideal for a survey where the personnel and team make up is changing fairly often.

1 Like

Wouldn’t that create an infinite loop?

  • interviewer completes an interview;
  • interview is rejected;
  • interviewer completes the edited interview;
  • edited interview is rejected;
  • interviewer completes the edited edited interview;
  • edited edited interview is rejected;

I assume in most use cases it would be a one time operation.
This might be because the interviewer consistently filled a question out in an incorrect manner.

If you wanted to disable an interviewer I assume it’d be better to archive their assignment or archive the interviewer.

For a one-time action, proceed to the interviews page, filter by name of responsible interviewer and completed status, bulk-select interviews and click ‘reject’.

Disabling an interviewer has multiple layers to that. But the most straightforward is to probably lock him out in his profile - a supervisor can do it.

Yes, this is the main point for me, that there doesn’t seem to be an easy way to map interviewers/supervisors to interview ids.
The rest of the steps are straightforward (though it’s good that you point out the difference between patch reject and patch hqreject)

When the interviewer has hundreds of interviews to reject, this is a very tedious process as you have to do it in batches of 20, especially when it’s multiple interviewers (under one supervisor who failed to pick up the problem)

It feels like there could be some pretty useful applications of an endpoint to map interviewers and supervisors to interviews, not just this one.