Europass import: every added entry gets order 0 and lands under the first one, not where its date puts it #618

New issue

Closed

opened 2026-10-01 10:48:25 +00:00 by tiagoagueda · 0 comments

tiagoagueda commented

2026-10-01 10:48:25 +00:00

Owner

Found on 2026-09-29 in a read-only review of postulo at 95348908d, comparing how each writer of career entries sets order, and settled by importing into a career that already had entries.

Checked again on 2026-10-01 against main at 0a5cad587: still present. The code is where it was; the wiki paragraph is now at Your-career-record.md:509-512 (postulo.wiki at 9aefad9b6), in the same words.

Since #203 each career section's order is dense and belongs to the person: a new dated entry is placed by its date and anything else goes last. The create view does this through ordering.place_new, and the candidate-file importer through candidate._place. The Europass writer does neither. importing.apply creates every experience, education, language, skill group, skill and project with objects.create() and never sets order, so each one keeps the default 0. Sections sort on ("order", "pk"), so every imported row lands straight after the existing entry at 0 and before the one at 1, in file order, whatever its date.

Where: resume/importing.py:189-254 (apply; no call into ordering anywhere in the module); the rule it skips is resume/ordering.py:81-98 (place_new), used by resume/views.py:278 and mirrored by resume/candidate.py:1334-1375 (_place). The wiki page Your-career-record.md:502-505 promises that a new experience, education or certification "lands where its date would put it" and anything else goes at the end.
What happens: checked with jobs starting in 2024, 2020 and 2016, each placed with place_new, then an import of jobs starting in 2022 and 2010. The section reads r2024 (0), r2022 (0), r2010 (0), r2020 (1), r2016 (2): the 2010 job sits above two newer ones. Imported languages, projects and skill groups likewise land second rather than last, and the numbers are no longer dense until an arrow is pressed.
Why it matters: the overview and every CV that follows the career's order show a jumbled history after an import, and the person has to repair each misplaced entry with the arrows, one step at a time.
Fix: place the rows importing.apply creates as candidate._place does: by ordering.DATE_FIELDS where the section has a date, last otherwise, then renumber densely. Moving that placement into resume/ordering.py and calling it from both importers would keep them from drifting.

Done when

A test in tests/test_career_ordering.py imports a Europass record into a career that already has dated experience and undated projects, and asserts that the experience reads newest first with dense numbers and that the projects come last.

Found on 2026-09-29 in a read-only review of postulo at 95348908d, comparing how each writer of career entries sets `order`, and settled by importing into a career that already had entries. Checked again on 2026-10-01 against `main` at `0a5cad587`: still present. The code is where it was; the wiki paragraph is now at `Your-career-record.md:509-512` (postulo.wiki at `9aefad9b6`), in the same words. Since #203 each career section's order is dense and belongs to the person: a new dated entry is placed by its date and anything else goes last. The create view does this through `ordering.place_new`, and the candidate-file importer through `candidate._place`. The Europass writer does neither. `importing.apply` creates every experience, education, language, skill group, skill and project with `objects.create()` and never sets `order`, so each one keeps the default 0. Sections sort on `("order", "pk")`, so every imported row lands straight after the existing entry at 0 and before the one at 1, in file order, whatever its date. - **Where:** `resume/importing.py:189-254` (`apply`; no call into `ordering` anywhere in the module); the rule it skips is `resume/ordering.py:81-98` (`place_new`), used by `resume/views.py:278` and mirrored by `resume/candidate.py:1334-1375` (`_place`). The wiki page `Your-career-record.md:502-505` promises that a new experience, education or certification "lands where its date would put it" and anything else goes at the end. - **What happens:** checked with jobs starting in 2024, 2020 and 2016, each placed with `place_new`, then an import of jobs starting in 2022 and 2010. The section reads `r2024 (0)`, `r2022 (0)`, `r2010 (0)`, `r2020 (1)`, `r2016 (2)`: the 2010 job sits above two newer ones. Imported languages, projects and skill groups likewise land second rather than last, and the numbers are no longer dense until an arrow is pressed. - **Why it matters:** the overview and every CV that follows the career's order show a jumbled history after an import, and the person has to repair each misplaced entry with the arrows, one step at a time. - **Fix:** place the rows `importing.apply` creates as `candidate._place` does: by `ordering.DATE_FIELDS` where the section has a date, last otherwise, then renumber densely. Moving that placement into `resume/ordering.py` and calling it from both importers would keep them from drifting. ## Done when - A test in `tests/test_career_ordering.py` imports a Europass record into a career that already has dated experience and undated projects, and asserts that the experience reads newest first with dense numbers and that the projects come last.

tiagoagueda added this to the 0.5.0 milestone

2026-10-01 10:48:25 +00:00

tiagoagueda added the

bug

tier

labels

2026-10-01 10:48:25 +00:00

tiagoagueda referenced this issue from a commit

2026-10-04 10:04:57 +00:00

Place Europass imports by date and last, as the candidate import does

tiagoagueda closed this issue

2026-10-04 10:04:57 +00:00