Interviews: editing one silently drops a contact who has since moved company or been merged elsewhere #443

New issue

Closed

opened 2026-10-01 10:46:44 +00:00 by tiagoagueda · 0 comments

tiagoagueda commented

2026-10-01 10:46:44 +00:00

Owner

Found on 2026-09-29 in a read-only review of postulo at 95348908d, comparing the interview form with the application form and checking the result with a unit test against the snapshot.

Checked again on 2026-10-01 against main at 0a5cad587: still present. The code is now at applications/views.py:977-987 (InterviewUpdateView.form_valid); applications/forms.py has not moved, and the same unit test gives the same result.

The interview form offers as contacts only the people currently recorded at the application's company. A contact already linked to the interview who is no longer there has no checkbox on the edit page, so any save of the form, for a new room or a moved hour, removes them from who you are meeting without a word. #239 fixed exactly this for an application's main contact; the interview form was left out.

Where: applications/forms.py:571-576 (InterviewForm.scope_querysets); saved by applications/views.py:937-947 (InterviewUpdateView.form_valid, form.save()). Compare applications/forms.py:377-385 (ApplicationForm.scope_querysets), which keeps Q(pk=self.instance.contact_id).
What happens: scope_querysets sets the queryset to Contact.objects.for_user(self.user).filter(company=self.application.posting.company_id) with no clause for the contacts already on the instance. CheckboxSelectMultiple renders only that queryset, so the browser posts nothing for the moved contact, and form.save() writes the many-to-many without them. Posting their id by hand is refused as "Select a valid choice". Checked: an interview scheduled with a contact at the employer, the contact then moved to another company, and an edit posted with a new location: the response was a redirect and interview.contacts.all() was empty. The edit page did not show the contact at all.
Why it matters: who was met at an interview is part of the record, shown on the interviews list and written into the diary file (applications/ical.py), and it disappears from an unrelated edit with nothing to say it did. Contacts do move company, and merging duplicate contacts (#239) moves them too.
Fix: in InterviewForm.scope_querysets, when self.instance.pk is set, widen the filter to Q(company=self.application.posting.company_id) | Q(pk__in=self.instance.contacts.values("pk")), still inside Contact.objects.for_user(self.user), and say beside such a contact where they are now so the person can untick them knowingly. Adjust the contacts help text, which says only people at this company are offered.

Done when

tests/test_interviews.py has a test mirroring the #239 one for the application form: schedule an interview with a contact, move the contact to another company, post an edit that changes only the location, and assert the contact is still linked.

Found on 2026-09-29 in a read-only review of postulo at 95348908d, comparing the interview form with the application form and checking the result with a unit test against the snapshot. Checked again on 2026-10-01 against `main` at `0a5cad587`: still present. The code is now at `applications/views.py:977-987` (`InterviewUpdateView.form_valid`); `applications/forms.py` has not moved, and the same unit test gives the same result. The interview form offers as contacts only the people currently recorded at the application's company. A contact already linked to the interview who is no longer there has no checkbox on the edit page, so any save of the form, for a new room or a moved hour, removes them from *who you are meeting* without a word. #239 fixed exactly this for an application's main contact; the interview form was left out. - **Where:** `applications/forms.py:571-576` (`InterviewForm.scope_querysets`); saved by `applications/views.py:937-947` (`InterviewUpdateView.form_valid`, `form.save()`). Compare `applications/forms.py:377-385` (`ApplicationForm.scope_querysets`), which keeps `Q(pk=self.instance.contact_id)`. - **What happens:** `scope_querysets` sets the queryset to `Contact.objects.for_user(self.user).filter(company=self.application.posting.company_id)` with no clause for the contacts already on the instance. `CheckboxSelectMultiple` renders only that queryset, so the browser posts nothing for the moved contact, and `form.save()` writes the many-to-many without them. Posting their id by hand is refused as "Select a valid choice". Checked: an interview scheduled with a contact at the employer, the contact then moved to another company, and an edit posted with a new location: the response was a redirect and `interview.contacts.all()` was empty. The edit page did not show the contact at all. - **Why it matters:** who was met at an interview is part of the record, shown on the interviews list and written into the diary file (`applications/ical.py`), and it disappears from an unrelated edit with nothing to say it did. Contacts do move company, and merging duplicate contacts (#239) moves them too. - **Fix:** in `InterviewForm.scope_querysets`, when `self.instance.pk` is set, widen the filter to `Q(company=self.application.posting.company_id) | Q(pk__in=self.instance.contacts.values("pk"))`, still inside `Contact.objects.for_user(self.user)`, and say beside such a contact where they are now so the person can untick them knowingly. Adjust the `contacts` help text, which says only people at this company are offered. ## Done when - `tests/test_interviews.py` has a test mirroring the #239 one for the application form: schedule an interview with a contact, move the contact to another company, post an edit that changes only the location, and assert the contact is still linked.

tiagoagueda added this to the 0.5.0 milestone

2026-10-01 10:46:44 +00:00

tiagoagueda added the

tier

bug

labels

2026-10-01 10:46:44 +00:00

tiagoagueda referenced this issue from a commit

2026-10-04 10:05:00 +00:00

Keep an interview's contact who has moved company when it is edited

tiagoagueda closed this issue

2026-10-04 10:05:00 +00:00