[wasud]

Decisions to review

• Stacking on two PRs: ni_questionnaire needs both the patient/observation stack ([17.0][MIG] ni_period, ni_identifier, ni_coding, partner_age, partner_gender, partner_religion, uom_alias: Migration to 17.0 #147 → [17.0][MIG] ni_patient: Migration to 17.0 #153 → [17.0][MIG] ni_observation: Migration to 17.0 #156) and the survey stack ([17.0][MIG] survey_subject, survey_grading: Migration to 17.0 #150). This branch is [17.0][MIG] ni_observation: Migration to 17.0 #156 plus the commits of [17.0][MIG] survey_subject, survey_grading: Migration to 17.0 #150 rebased on top (the shared [FIX] 17.0 pre-commit commit is dropped as already applied), then ni_questionnaire. After [17.0][MIG] survey_subject, survey_grading: Migration to 17.0 #150 and [17.0][MIG] ni_observation: Migration to 17.0 #156 merge, a rebase leaves only the ni_questionnaire commits.
• Behaviour fixes in the encounter questionnaire flow. All four bugs already happen on 16.0; they are fixed here because the issue requires the start/print-from-encounter flow to work:
  1. survey_token is not a context key Odoo reads (16–19), and response.token is not a field (access_token). The second click on "Start Questionnaire" raised AttributeError, and printing opened a blank survey. Now it uses core action_start_survey(answer=…) / action_print_survey(answer=…).
  2. The response was created with partner=<patient>. Core then rejects the logged-in clinician with "Survey Access Error" (answer_wrong_user). It is now created like the survey_subject wizard: user=env.user, subject = the encounter.
  3. The response from the encounter button had no patient_id/encounter_id, so the observation from the score had no patient. Both are now set, like the wizard does.
  4. The encounter's "latest response" (and the "Print Questionnaire" button that depends on it) never updated after completion. The stored compute read the ni.encounter.survey_latest SQL view, which cannot see the response before the ORM flushes, and it had no dependency on state. It now reads response_ids through the ORM and depends on response_ids.state.
• subject_type uses selection_add (ondelete = set default) instead of redeclaring survey_subject's whole selection.
• sudo_compute → compute_sudo (typo, unknown parameter warning). P0-4 ([MIG 19.0][P0-4][FIX] Pre-existing bugs found during the 19.0 migration scan (16.0) #135) fixes the same on 16.0; the forward port is trivial.

What changed

• ni_questionnaire history replayed, then [IMP] pre-commit and [MIG] ni_questionnaire: Migration to 17.0.
• Migrator: attrs → expressions (including the <attribute name="attrs"> override on the response form), version.
• Manual work:
  • Conditional questions: the tests now use triggering_answer_ids (17 removed is_conditional, triggering_question_id, triggering_answer_id).
  • Encounter compute assigns instead of write().
  • Hidden list fields use column_invisible.
  • Thai text the migrator encoded as entities restored.
• Reports:
  • The two "latest survey" SQL views select an explicit column list from survey_user_input (SQL() with identifiers), instead of SELECT … *.
  • The monthly line report keeps only its _table_query (its init() created the same view a second time).
• New tests tests/test_encounter_survey.py: start creates and reuses the encounter's response (with patient, encounter, current user); print uses it; the latest response follows completion.
• Lint: named translation placeholders, init() returns super(), redundant labels.
• th.po regenerated (new msgids filled).

Why

Part of #140 (P1-5, epic #131).

Migration notes

• Effort: L.
• What the migrator did: attrs in 9 view files.
• Manual work:
  • conditional tests;
  • the encounter flow (4 pre-existing bugs);
  • report SQL;
  • selection_add;
  • lint backlog.
• Surprises:
  • The encounter start/print flow never worked as designed on 16.0. survey_token was never an Odoo API, and the patient partner blocks the clinician.
  • Stored computes over SQL views read stale data.

How tested

• Unit/integration tests: 32 tests pass on 17 (29 existing + 3 new), fresh DB.
• Manual check (browser, Odoo 17 with demo data). Questionnaire with a conditional question, a score → observation mapping and two grades.
  • Encounter "Start Questionnaire" opens the encounter's response.
  • Answering "Yes" shows the conditional question; submit.
  • Score 10, grade "High", grading reference shown.
  • Observation "Smoke Score = 10" created on the encounter.
  • "Print Questionnaire" appears and prints the answers.
  • Encounter Questionnaire tab (latest survey: grade, score), monthly pivot report.
  • No JS console errors.
• pre-commit clean on ni_questionnaire.

Documentation

• Module README.md updated (17.0, subject types, encounter flow, report views, tests)

Notes for reviewer

• Added after review started (P1-6 pilot, [MIG 19.0][P1-6] Data migration pilot: OpenUpgrade 16→17→18→19 on Phase 1 modules #141): [FIX] ni_questionnaire: recompute the encounters' latest response on upgrade adds migrations/17.0.1.0.0/post-migration.py. The 16.0 stored response_latest_id/grade/date are empty or stale (the bug fixed here), and nothing recomputes them on upgrade, so migrated encounters showed no latest grade and no "Print Questionnaire" button. Checked on the pilot DB: 6 of 6 encounters with a completed questionnaire get their latest response; values carry through 18 and 19. Branch rebased on the updated [17.0][MIG] ni_observation: Migration to 17.0 #156.

• Stacked on [17.0][MIG] ni_observation: Migration to 17.0 #156 (P1-4 17.0) and [17.0][MIG] survey_subject, survey_grading: Migration to 17.0 #150 (P1-3 17.0). Merge those first.

[piruin]

Review of ni_questionnaire only (the patient/observation/survey commits belong to the stacked PRs).

Blocking — clinicians can't start the questionnaire from the encounter on 17.0 (models/ni_encounter.py, action_start_survey)

self.survey_id._create_answer(...) runs as the logged-in user without sudo(). In 17.0 core, survey_user_input_rule_survey_user_cw only allows a survey officer to create a survey.user_input for a survey they created (survey_id.create_uid = user). Clinicians only get survey.group_survey_user (implied by ni_patient.group_viewer), so anyone who did not create the survey gets an AccessError. The survey_subject wizard works because it calls self.sudo().survey_id._create_answer(...). The new tests run as superuser (record rules skipped) and the manual check used admin, so neither covers this. Since the PR states the start-from-encounter flow now works, this is in scope even though 16.0 has the same bug.

Suggested: .sudo() like the wizard, plus a test that calls encounter.with_user(<user in ni_patient.group_user only>).action_start_survey(). (18.0/19.0 core lets officers create on unrestricted surveys, so #160/#161 are not affected.)

Medium — subject wizard now shows the patient/encounter pickers that 16.0 hid (wizard/survey_subject_views.xml)

On 16.0, subject_ni_patient / subject_ni_encounter had invisible="context.get('default_subject_ni_…')" next to attrs. A truthy context value overrode the attrs domain (16.0 core ir_ui_view.py, context-dependent modifiers). The 17.0 conversion kept only type not in [...], so opening the wizard from an encounter or observation ("Start Survey") now shows editable patient/encounter fields. Suggested:

invisible="context.get('default_subject_ni_patient') or type not in ['ni.patient', 'ni.encounter']"

(and the same with default_subject_ni_encounter for subject_ni_encounter). This is the only element in the module that had both.

Low — the latest-response view and compute break ties differently (report/ni_patient_survey_latest.py)

The survey_latest views order by create_date DESC with no tie-breaker, while ni.encounter._compute_response sorts by (create_date, id). If two done responses share a create_date (e.g. created in one transaction), response_latest_id can point to a row the view's DISTINCT ON dropped. Adding , id DESC to the view's ORDER BY aligns them (and matches the index, which already includes id).

Nit — the error branch of _answer_group_observation raises AttributeError (models/survey_user_input.py)

code is group.observation_code_id, already an ni.observation.type, which has no observation_type_id. So code.observation_type_id.name / .value_type crash instead of raising the ValidationError. Mostly unreachable thanks to the field domain, but these lines were just rewritten; use code.name / code.value_type.

Note (non-blocking) — creating the answer with user=env.user counts attempts against the clinician's partner, not the patient's. On a survey with limited attempts, a clinician runs out across patients. The survey_subject wizard behaves the same way.

Checked and fine: attrs conversions (apart from the wizard), selection_add with ondelete, action_start_survey(answer=) / action_print_survey(answer=), compute dependencies, the post-migration recompute, and the explicit view column list (covers every stored field of the view model).

[wasud]

Thanks for the review. Pushed (head d4997b7e); the fixes are in [MIG] ni_questionnaire: Migration to 17.0, and #160/#161 replay them.

• Blocking, start from the encounter: action_start_survey now calls self.survey_id.sudo()._create_answer(...), like the survey_subject wizard. New test test_start_as_clinician runs encounter.with_user(clinician).action_start_survey() with a user in ni_patient.group_user only, who did not create the survey. Before the fix it raised the AccessError; now it passes. The response is still created for the clinician's partner, so core lets them in.
• Subject wizard pickers: subject_ni_patient / subject_ni_encounter are hidden again when default_subject_ni_patient / default_subject_ni_encounter is in the context, as you suggested.
• Tie-breaker: the survey_latest views now order by create_date DESC, id DESC. New test test_latest_response_ties_on_create_date: two done responses created in one transaction share their create_date, and the view and response_latest_id both pick the last one. It failed before the fix.
• Nit: the error branch of _answer_group_observation uses code.name / code.value_type. New test test_group_needs_a_numeric_observation_type (it raised AttributeError before, ValidationError now).
• Note on attempts: left as is. The encounter flow and the survey_subject wizard both count attempts against the clinician's partner, so they still behave the same. If limited attempts per patient are needed, that is a separate change for both flows.
• The same sudo() bug exists on 16.0. I can add it to the P0-4 fixes ([16.0][FIX] Pre-existing bugs found during the 19.0 migration scan #166) if you want it there too.

Tests: 93 pass on a fresh 17.0 database (ni_patient, ni_observation, ni_questionnaire, ni_partner_*); pre-commit passes.