Applying from a listing: the tags help points to a 'box below' that is not there, and typed tags are dropped #408

New issue

Closed

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

tiagoagueda commented

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

Owner

Found on 2026-09-29 in a read-only review of postulo at 95348908d, reading the three pages that use ApplicationDetailsForm and posting to the listing's Apply page with the test client.

Checked again on 2026-10-01 against main at 0a5cad587: still present.

The Apply page of a listing uses the same form as the intake page, but draws its tags as a plain field and saves only the ticked ones. The help text under the field still says "New ones go in the box below", and there is no box, so a person applying from a listing cannot add a new tag there and is told that they can.

Where: templates/jobs/listing_apply.html:40 (<c-field :field="form.tags" />); jobs/listing_views.py:319 in ListingApplyView.post (application.tags.set(form.cleaned_data["tags"])); the help text at applications/forms.py:50 (APPLICATION_HELP["tags"]); the new_tags field and chosen_tags() at applications/forms.py:272-292.
What happens: GET /listings/<pk>/apply/ contains "New ones go in the box below" and no name="new_tags" input. A POST with new_tags=Urgent records the application with no tags. The intake page (applications/application_intake.html:63) and the edit page (applications/application_form.html:27) include partials/tags_field.html, which renders the new-tags box, and ApplicationCreateView saves with form.chosen_tags() (applications/views.py:429).
Why it matters: the page tells the person to do something it offers no way to do, and the tag has to be added afterwards on the edit page. partials/tags_field.html exists so that the pages showing tags "cannot drift" (#139); this third page was added without it and drifted.
Fix: include partials/tags_field.html in place of the c-field at listing_apply.html:40, and save with application.tags.set(form.chosen_tags()) in ListingApplyView.post, as ApplicationCreateView does.

Done when

A test in tests/test_labels.py (or the listing tests) asserts that the listing's Apply page renders name="new_tags" and data-labels-existing, and that posting new_tags=Urgent leaves the new application tagged Urgent; both fail today.

Found on 2026-09-29 in a read-only review of postulo at 95348908d, reading the three pages that use `ApplicationDetailsForm` and posting to the listing's *Apply* page with the test client. Checked again on 2026-10-01 against `main` at `0a5cad587`: still present. The *Apply* page of a listing uses the same form as the intake page, but draws its tags as a plain field and saves only the ticked ones. The help text under the field still says "New ones go in the box below", and there is no box, so a person applying from a listing cannot add a new tag there and is told that they can. - **Where:** `templates/jobs/listing_apply.html:40` (`<c-field :field="form.tags" />`); `jobs/listing_views.py:319` in `ListingApplyView.post` (`application.tags.set(form.cleaned_data["tags"])`); the help text at `applications/forms.py:50` (`APPLICATION_HELP["tags"]`); the `new_tags` field and `chosen_tags()` at `applications/forms.py:272-292`. - **What happens:** `GET /listings/<pk>/apply/` contains "New ones go in the box below" and no `name="new_tags"` input. A `POST` with `new_tags=Urgent` records the application with no tags. The intake page (`applications/application_intake.html:63`) and the edit page (`applications/application_form.html:27`) include `partials/tags_field.html`, which renders the new-tags box, and `ApplicationCreateView` saves with `form.chosen_tags()` (`applications/views.py:429`). - **Why it matters:** the page tells the person to do something it offers no way to do, and the tag has to be added afterwards on the edit page. `partials/tags_field.html` exists so that the pages showing tags "cannot drift" (#139); this third page was added without it and drifted. - **Fix:** include `partials/tags_field.html` in place of the `c-field` at `listing_apply.html:40`, and save with `application.tags.set(form.chosen_tags())` in `ListingApplyView.post`, as `ApplicationCreateView` does. ## Done when - A test in `tests/test_labels.py` (or the listing tests) asserts that the listing's *Apply* page renders `name="new_tags"` and `data-labels-existing`, and that posting `new_tags=Urgent` leaves the new application tagged *Urgent*; both fail today.

tiagoagueda added this to the 0.6.0 milestone

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

tiagoagueda added the

interface

bug

tier

labels

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

tiagoagueda referenced this issue from a commit

2026-10-04 09:26:54 +00:00

Offer the new-tags box on a listing's Apply page

tiagoagueda closed this issue