Skip to content

Add people and case question flow - #148

Open
nonprofittechy wants to merge 18 commits into
workflow/document-prepfrom
workflow/people
Open

Add people and case question flow#148
nonprofittechy wants to merge 18 commits into
workflow/document-prepfrom
workflow/people

Conversation

@nonprofittechy

Copy link
Copy Markdown
Member

Summary

Fifth PR in the staged filing-flow migration. This replaces the remaining people-screen bridges with durable, resumable screens:

  • adds filer contact confirmation, prefilled from the Illinois eFile profile when available
  • adds a party roster with court-provided roles rendered as radio buttons
  • creates missing required-party slots and repeats the party-details screen until each is complete
  • supports person and organization parties with durable contact/address data
  • renders configured case questions only when the selected case type has them
  • preserves a compatibility serialization for the existing fees/submission slice

Stacked on #147; review only the people-flow commit.

Screenshots

Your information

Your information

Parties

Parties

Repeating party details

Party details

Conditional case questions

Case questions

Validation

  • uv run pytest -q — 211 passed
  • npm run test:unit — 17 passed
  • Ruff, djlint, CSS/JS formatting, type checks, migration check, and git diff --check passed

Copilot AI left a comment

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Pull request overview

This PR advances the staged filing-flow migration by replacing the remaining “people” legacy bridges with durable (workflow v2) screens for filer contact info, party roster + repeating party-details capture, and conditional case questions, while keeping legacy payload compatibility via draft serialization updates.

Changes:

  • Adds new v2 Django views + templates for Your information, Parties, Party details (repeat-until-complete), and Case questions.
  • Introduces party type display name persistence (party_type_name) and exposes a filing_parties list in read_case_data() for bridging.
  • Adds client-side enhancements + styling for the new people flow, plus unit tests covering the new flow.

Reviewed changes

Copilot reviewed 20 out of 24 changed files in this pull request and generated 5 comments.

Show a summary per file
File Description
efile_app/efile/views/your_information.py New v2 view to persist filer contact/address and advance to Parties.
efile_app/efile/views/parties.py New v2 party roster view: select filer role, ensure required parties, manage additional parties.
efile_app/efile/views/party_details.py New v2 repeating party details capture and step advancement logic.
efile_app/efile/views/case_questions.py New v2 case-questions screen with typed parsing and persistence to supplemental_fields.
efile_app/efile/urls.py Routes people-flow URLs directly to new v2 views (removes legacy redirect bridges).
efile_app/efile/tests/test_reorganized_start.py Removes test asserting unmigrated people screens redirect to legacy flow.
efile_app/efile/tests/test_people_flow.py Adds test coverage for the new people flow behavior and legacy payload bridge.
efile_app/efile/tests/test_document_prep.py Minor assertion ordering adjustment in an existing test.
efile_app/efile/templates/efile/your_information.html New workflow UI for filer contact confirmation.
efile_app/efile/templates/efile/parties.html New workflow UI for selecting filer role and managing party roster.
efile_app/efile/templates/efile/party_details.html New workflow UI for capturing person/org party details.
efile_app/efile/templates/efile/case_questions.html New workflow UI for conditional case questions.
efile_app/efile/static/js/your-information.js Prefills filer contact fields from /api/auth/profile/.
efile_app/efile/static/js/party-details.js Toggles person vs. organization fields and required attributes.
efile_app/efile/static/js/case-questions.js Conditional show/require logic for child-count question.
efile_app/efile/static/css/reorganized-flow.css Styling for people-flow layouts (cards, roster rows, question cards).
efile_app/efile/services/people.py Adds party completeness checks, required-party creation, and question configuration/parsing helpers.
efile_app/efile/services/drafts.py Extends legacy serialization to include filer-derived petitioner fields and filing_parties.
efile_app/efile/models.py Adds FilingParty.party_type_name.
efile_app/efile/migrations/0006_filingparty_party_type_name.py Migration adding party_type_name column.
Suppressed comments (1)

efile_app/efile/views/parties.py:85

  • The roster marks a party "complete" based on role + name only, but the workflow requires a mailing address too (and incomplete_parties() uses address fields). This can show "Complete" for parties that will still be forced back through Party Details.
            "party": party,
            "complete": bool(party.party_type and (party.organization_name or (party.first_name and party.last_name))),
        }

💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.

Comment thread efile_app/efile/views/parties.py
Comment thread efile_app/efile/views/party_details.py Outdated
Comment thread efile_app/efile/views/case_questions.py
Comment thread efile_app/efile/migrations/0006_filingparty_party_type_name.py
Comment thread efile_app/efile/views/party_details.py
nonprofittechy and others added 3 commits August 10, 2026 18:46
Validate filer/party role codes against the court's party_types before
persisting, restrict party_details editing to non-filer parties (the
?party= query param previously allowed editing any party in the draft,
including the filer), backfill party_type_name via preserve_default so
existing rows get a real default during migration, reuse party_is_complete
for the roster "complete" flag so it checks address like incomplete_parties
does, and normalize case-question radio prefill values so both legacy
string answers and newly-typed booleans preselect correctly.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
@nonprofittechy
nonprofittechy marked this pull request as ready for review August 10, 2026 22:47
nonprofittechy and others added 15 commits August 10, 2026 20:20
…kflow/people

# Conflicts:
#	efile_app/efile/tests/test_document_prep.py
…rest

Extends the return_to=review mechanism (introduced for extraction_review
and organize_documents) to your_information, parties, party_details, and
case_questions: editing one of these from the Review screen now saves
and sends the filer back to Review, instead of continuing forward
through every later screen in the linear workflow.

return_to threads through the intermediate redirects too (adding a
party, filling in a still-incomplete required party) so it survives to
reach whichever step it names.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
…kflow/people

# Conflicts:
#	efile_app/efile/tests/test_reorganized_start.py
A new case is almost always opened by the plaintiff/petitioner; filing
an Answer almost always means the filer is the defendant/respondent.
Surface that as a dismissible hint with an "Apply guess" button next
to "What is your role in this case?" instead of pre-filling the
radio -- it's a heuristic on case posture alone, not something to
silently decide on the filer's behalf. Hidden once a role is already
chosen so it doesn't nag after the fact, and absent entirely when
neither signal applies (existing case, no Answer filed).

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Suffix has to exactly match one of the court's own codes (Jr., Sr.,
III, ...) to be accepted, same as court/case category/type already
are. Load the options from the new name-suffixes endpoint on both
your_information (the filer) and party_details (other parties);
if a draft already has a free-text value that isn't in the court's
list, keep it as a selectable option instead of silently dropping it.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
…kflow/people

# Conflicts:
#	efile_app/efile/tests/test_document_prep.py
Continues the amount-in-controversy work from document-prep (which
records FilingDocument.filing_requires_amount_in_controversy from the
Tyler filing-types flag). case_questions now asks for the dollar
amount whenever any organized document needs it -- even when the
case-type config has no other dynamic questions to ask, which used to
make the page skip itself straight to payment before this check
existed. parties and party_details route to case_questions on that
same combined condition, not just the config-driven question list.

Saved to draft.amount_in_controversy (a dedicated column, not
supplemental_fields -- that field is documented as config-driven only).

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
incomplete_parties() correctly sent this test's draft to party_details
first (the auto-created required "defendant" party had no name/address
yet), before it ever reached the has_questions routing this test
meant to check. Give it a complete one instead, like the sibling
return_to test already does.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants