diff --git a/README.md b/README.md index 57ce6da..5830f80 100644 --- a/README.md +++ b/README.md @@ -2,7 +2,7 @@ A minimal Django app for form submission and review. The Django project lives under `efile_app/` with settings in `efile_app/efile/`. -## Quick Start +## Quick start - __Requirements__ - Python 3.10+ @@ -73,11 +73,11 @@ Deactivate with `deactivate` when you're done. - __Static files__ During development, static files are served automatically. No `collectstatic` is needed. -## AWS S3 Setup (Required for File Uploads) +## AWS S3 setup (required for file uploads) The application uses AWS S3 for document storage and file uploads. Follow these steps to set up your S3 bucket: -### 1. Create an S3 Bucket +### 1. Create an S3 bucket - Log into the AWS Console and navigate to S3 - Create a new bucket (e.g., `litefile-your-suffix`) @@ -86,7 +86,7 @@ The application uses AWS S3 for document storage and file uploads. Follow these - Tags can be created to help track ownership of resources and is useful for cost tracking, environment tracking, etc. - Default encryption settings should be fine -### 2. Configure Bucket Permissions +### 2. Configure bucket permissions Apply this bucket policy to allow public read access for Tyler to download documents: @@ -107,7 +107,7 @@ Apply this bucket policy to allow public read access for Tyler to download docum Replace `YOUR-BUCKET-NAME` with your actual bucket name. -### 3. Create IAM User and Permissions +### 3. Create IAM user and permissions Create an IAM user with the following policy for application access: @@ -134,14 +134,14 @@ Create an IAM user with the following policy for application access: } ``` -### 4. Disable Public Access to the S3 Bucket +### 4. Disable public access to the S3 bucket You can now turn on "Block all public access" in the S3 bucket settings. Go to Permissions. Click on the Edit button in the "Block public access (bucket settings)" section. Toggle on "Block all public access". Click "Save Changes" and confirm the action. This will keep the existing policy, which we use to generate the pre-signed URLs to Tyler access, but restrict the files from being made publicly accessible in other ways. -### 5. Configure Environment Variables +### 5. Configure environment variables Copy the example environment file and update the S3 settings: @@ -152,7 +152,7 @@ cp efile_app/.env.example efile_app/.env Edit `efile_app/.env` with your AWS credentials: ```bash -# AWS S3 Configuration +# AWS S3 configuration AWS_ACCESS_KEY_ID = "your-aws-access-key-id-here" AWS_SECRET_ACCESS_KEY = "your-aws-secret-access-key-here" AWS_S3_BUCKET_NAME = "your-bucket-name-here" @@ -224,7 +224,7 @@ Notes: - `DJANGO_SETTINGS_MODULE` is set to `efile.settings` in `[tool.pytest.ini_options]`. - Tests are discovered under `efile_app/`. An example smoke test lives at `efile_app/efile/tests/test_smoke.py`. -## End-to-End Testing (Playwright) +## End-to-end testing (Playwright) Playwright tests are located in `efile_app/tests/` and provide browser-based testing of the complete user workflow. These are intended to be run manually and are not part of the CI/CD pipeline because they produce side-effects (e.g. filing new cases in EFSP) and rely on external APIs (e.g. EFSP again). The tests stop short @@ -259,7 +259,7 @@ The Playwright configuration includes several important settings: - **Parallel Execution**: Disabled on CI (1 worker) to avoid conflicts with external services - **Browser**: Currently configured for Chromium only (Firefox and Safari commented out) -### Running Tests +### Running tests - __Start the Django server__ first: ```bash @@ -295,7 +295,7 @@ The Playwright configuration includes several important settings: **Note**: The global setup automatically validates your `.env` configuration before running tests. If environment variables are missing, tests will fail with a clear error message. -### Test Architecture +### Test architecture The Playwright tests use a modular architecture with shared utilities: @@ -303,7 +303,7 @@ The Playwright tests use a modular architecture with shared utilities: - **`tests/test-utils.js`**: Shared utilities including `loginViaLogout()`, `loginViaLoginPage()`, and `getTestConfig()` functions - **`playwright.config.js`**: Playwright configuration with global setup enabled, extended timeout, and CI-specific settings -#### Login Utilities +#### Login utilities The `test-utils.js` module provides two login methods: @@ -311,7 +311,7 @@ The `test-utils.js` module provides two login methods: - **`loginViaLoginPage(page, config)`**: Logs in via the `/login` page - **`loginUser(page, config)`**: Alias for `loginViaLogout()` for backward compatibility -### Available Tests +### Available tests - **`expert-form-name-change.spec.js`**: Tests the complete workflow for filing a name change case - **`expert-form-order-of-protection.spec.js`**: Tests the complete workflow for filing an order of protection case @@ -359,7 +359,7 @@ Pre-commit hooks are configured in `.pre-commit-config.yaml` to run Ruff formatt **Note**: The pytest hook runs on `pre-push` stage to keep commits fast. If you skip the pre-push hook installation, tests won't run automatically before pushing. -## Project Layout +## Project layout - `efile_app/manage.py` — Django management script - `efile_app/efile/settings.py` — Project settings (uses SQLite by default; DB file at `efile_app/db.sqlite3`) diff --git a/docs/sample_simple_form_config.md b/docs/sample_simple_form_config.md index 6111a54..91dde36 100644 --- a/docs/sample_simple_form_config.md +++ b/docs/sample_simple_form_config.md @@ -1,5 +1,5 @@ -### Hypothetical Flow Config +### Hypothetical flow config The Filing Flow config language follows these design principles: @@ -20,7 +20,7 @@ The Filing Flow config language follows these design principles: - **Instructions**: Plain-language guidance at flow and step levels ```yaml -# Illinois Adult Name Change - Cook County Filing Flow +# Illinois adult name change - Cook County filing flow # NOTE: this is hypothetical and collects more data than necessary for the real e-filing since we merge data from # the Tyler profile. # NOTE: to match the actual wireframes, this simple flow should've allowed for adult or child. We'd need a form diff --git a/docs/vision-eval-20250827.md b/docs/vision-eval-20250827.md index a8d5106..56ed68e 100644 --- a/docs/vision-eval-20250827.md +++ b/docs/vision-eval-20250827.md @@ -1,4 +1,4 @@ -# Status Check vs Vision +# Status check vs vision Based on the current codebase, here’s where things stand relative to your MVP vision. ## What’s in place @@ -20,7 +20,7 @@ Based on the current codebase, here’s where things stand relative to your MVP - __Uploads and mapping to EFSP__ - `efile/views/upload.py` implements `create_filing()` (maps session → Suffolk payload) and `upload_documents()` (S3 → Suffolk document registration), plus mock/simple upload utilities. -## Gaps vs Vision +## Gaps vs vision - __Filing Flow runner (recipe-driven)__: No generalized sequence/branch/validate engine or persisted recipes for curated flows. - __Form Blocks abstraction and UI__: No explicit Form Block schema/type library and reusable UI components. @@ -31,7 +31,7 @@ Based on the current codebase, here’s where things stand relative to your MVP - __Configuration management UX__: No admin UI for non-technical authoring/editing of Blocks/Flows. - __Tests__: Limited tests for flow engine, YAML court overrides, and EFSP interactions. -## Recommended Next Steps (MVP-targeted) +## Recommended next steps (MVP-targeted) 1. __Introduce a Filing Flow “recipe” format (JSON/YAML)__ - Minimal schema: metadata (`id`, `title`, `jurisdiction`), steps (Form Blocks), branching (`next_if`, `next_else`), validation, mapping. @@ -68,7 +68,7 @@ Based on the current codebase, here’s where things stand relative to your MVP 8. __Tests__ - Flow runner branching/validation; config merging for courts (e.g., `cook:cd1` vs `cook:chd1` per `efile/static/config/README.md`); mapping integration tests. -## Concrete Implementation Plan +## Concrete implementation plan - __Backend__ - Create `efile/flow/`: `schemas.py` (dataclasses/Pydantic for Block/Step/Recipe), `runner.py`, `mapping.py`, (optional) `models.py` for persistence. @@ -81,13 +81,13 @@ Based on the current codebase, here’s where things stand relative to your MVP - Reuse dropdown endpoints and party types via `config_views.py` and Suffolk codes. - Reuse S3 patterns from `upload.py`. -## Open Questions +## Open questions - Recipes YAML (human-friendly) or JSON (browser-native)? Suggest YAML in repo + compile to JSON at runtime. - Attachments: embed file-upload blocks in steps now or upload at review step? - Initial guided flow: Illinois Name Change (best documented today)? -## Proposed Short Milestones +## Proposed short milestones - __M1 (day 1-2)__: Schemas + runner skeleton (load/next/back), session storage, minimal API. - __M2 (day 3-4)__: Mapping layer + Review & Submit, integrate with `create_filing()`. diff --git a/docs/vision-eval-20250902.md b/docs/vision-eval-20250902.md index 5437a28..4055530 100644 --- a/docs/vision-eval-20250902.md +++ b/docs/vision-eval-20250902.md @@ -1,31 +1,31 @@ -# Vision Evaluation - September 2, 2025 +# Vision evaluation - September 2, 2025 -## Executive Summary +## Executive summary The current Form Submission MVP demonstrates solid progress toward the vision goals, with core infrastructure in place and key user flows implemented. The app successfully implements EFSP integration, session-based data management, and a working filing flow for Illinois Adult Name Change cases. However, several vision components remain incomplete or need refinement. **Overall Assessment: 70% Complete** -## Vision Goal Analysis +## Vision goal analysis -### ✅ **Achieved Goals** +### ✅ **Achieved goals** -#### EFSP REST API Integration +#### EFSP REST API integration - **Status**: ✅ Complete - **Implementation**: Full integration with Suffolk's EFSP API for authentication, options discovery, and filing submission - **Evidence**: Comprehensive API views in `efile/api/` directory, auth handling, dropdown population from live API data -#### Session Data Management +#### Session data management - **Status**: ✅ Complete - **Implementation**: Robust session-based data storage with structured case data, party information, and file uploads - **Evidence**: Session API endpoints, data persistence across flow steps, temporary file storage -#### Basic Auth/Session +#### Basic auth/session - **Status**: ✅ Complete - **Implementation**: Django-based authentication with user registration, login/logout, and session management - **Evidence**: User registration forms, login views, session-based auth tokens -#### Local Deploy via Docker/Compose +#### Local deploy via Docker/Compose - **Status**: ✅ Complete - **Implementation**: Full Docker setup with compose configuration - **Evidence**: `Dockerfile`, `compose.yml`, and environment-specific settings @@ -35,66 +35,66 @@ The current Form Submission MVP demonstrates solid progress toward the vision go - **Implementation**: GitHub Actions workflow with type checking, linting, and testing - **Evidence**: `.github/workflows/ci.yml`, pyproject.toml configuration -#### Illinois Adult Name Change Support +#### Illinois adult name change support - **Status**: ✅ Complete - **Implementation**: Dedicated case type configuration and form handling for Cook County Adult Name Change - **Evidence**: Case type config in `case_type_config.yml`, specialized form validation -### 🔄 **Partially Implemented** +### 🔄 **Partially implemented** -#### Form Blocks Architecture +#### Form blocks architecture - **Status**: 🔄 Partial (40%) - **Current State**: Basic form components exist but not as reusable, configurable blocks - **Gap**: Forms are hardcoded rather than built from composable Form Block components - **Next Steps**: Refactor forms to use configurable Form Block system -#### Filing Flow Runner +#### Filing flow runner - **Status**: 🔄 Partial (60%) - **Current State**: Linear flow exists (login → options → expert form → upload → review → submit) - **Gap**: No configuration-driven flow system; flows are hardcoded in views - **Next Steps**: Implement YAML-based Filing Flow configuration system -#### Review & Submit Step +#### Review & submit step - **Status**: 🔄 Partial (70%) - **Current State**: Review page exists with case data summary - **Gap**: Summary could be more human-readable; needs better formatting - **Next Steps**: Enhance review page with clearer data presentation -#### Mapping Layer +#### Mapping layer - **Status**: 🔄 Partial (50%) - **Current State**: Basic field mapping exists in forms and API calls - **Gap**: No centralized, configurable mapping system - **Next Steps**: Create declarative mapping configuration system -### ❌ **Missing Components** +### ❌ **Missing components** -#### Configuration-Driven Form Blocks +#### Configuration-driven form blocks - **Status**: ❌ Not Implemented - **Vision**: Small set of validated input blocks (text, select, date, address) with basic theming - **Current State**: Hardcoded Django forms - **Impact**: Non-technical users cannot configure workflows without code changes -#### Self-Service Filing Flow Configuration +#### Self-service filing flow configuration - **Status**: ❌ Not Implemented - **Vision**: Non-technical users can create/edit Filing Flows without code - **Current State**: All flows are hardcoded in Python/templates - **Impact**: Major blocker for vision goal of self-service configuration -#### Multiple Case Type Support +#### Multiple case type support - **Status**: ❌ Limited - **Vision**: Proof of feasibility for at least 2 other case types beyond Adult Name Change - **Current State**: Only Adult Name Change fully implemented - **Impact**: Cannot demonstrate system flexibility -#### Guided Interview Experience +#### Guided interview experience - **Status**: ❌ Not Implemented - **Vision**: Plain-language labels, helper text, step-by-step guidance - **Current State**: Expert form is technical and overwhelming - **Impact**: Poor user experience for self-represented litigants -## User Experience Assessment +## User experience assessment -### Current User Journey +### Current user journey 1. **Registration/Login**: ✅ Working, clean interface 2. **Options Selection**: ✅ Functional but technical (expert mode only) 3. **Case Details**: ✅ Working but complex form @@ -102,13 +102,13 @@ The current Form Submission MVP demonstrates solid progress toward the vision go 5. **Review**: ✅ Basic summary provided 6. **Submission**: ✅ EFSP integration working -### UX Gaps vs Vision +### Ux gaps vs vision - **Clarity**: Current interface is expert-focused, not beginner-friendly - **Guidance**: Lacks step-by-step guidance and plain-language instructions - **Progressive Disclosure**: Shows all options at once rather than guided flow - **Error Handling**: Basic validation exists but could be more user-friendly -## Technical Architecture Assessment +## Technical architecture assessment ### Strengths - **Solid Foundation**: Django app with proper structure and separation of concerns @@ -117,38 +117,38 @@ The current Form Submission MVP demonstrates solid progress toward the vision go - **Configuration Start**: Beginning of configuration system with YAML files - **Testing Infrastructure**: CI/CD pipeline with proper tooling -### Areas for Improvement +### Areas for improvement - **Form Block Architecture**: Need composable, reusable form components - **Configuration System**: Expand YAML-based configuration for full Filing Flows - **Error Handling**: Enhance user-facing error messages and recovery flows - **UI Components**: Move toward more modular, themeable UI components -## Success Metrics Progress +## Success metrics progress -### Time-to-Submit (Target: 15 minutes) +### Time-to-submit (target: 15 minutes) - **Current**: Estimated 20-25 minutes for technical users - **Gap**: Expert form complexity adds time; needs guided flow -### First-Pass Acceptance (Target: ≥80%) +### First-pass acceptance (target: ≥80%) - **Current**: Unknown (needs testing) - **Blocker**: Limited real-world testing data -### Self-Service Configuration (Target: Non-technical user can edit flows) +### Self-service configuration (target: Non-technical user can edit flows) - **Current**: 0% - All configuration requires code changes - **Critical Gap**: No visual or YAML-based flow configuration -### Fast Onboarding (Target: Quick Docker setup) +### Fast onboarding (target: Quick docker setup) - **Current**: ✅ Achieved - Docker compose setup works well -## Priority Recommendations +## Priority recommendations -### High Priority (Core Vision Blockers) +### High priority (core vision blockers) 1. **Implement Form Block Architecture**: Create reusable, configurable form components 2. **Build Filing Flow Configuration System**: YAML-based flow definitions 3. **Create Guided Interview Mode**: User-friendly alternative to expert form 4. **Add 2 More Case Types**: Demonstrate system flexibility -### Medium Priority (UX Improvements) +### Medium priority (ux improvements) 1. **Enhance Error Handling**: Better user-facing error messages 2. **Improve Review Page**: More readable data summary 3. **Add Helper Text System**: Step-by-step guidance and instructions diff --git a/docs/vision.md b/docs/vision.md index 266b650..51453ad 100644 --- a/docs/vision.md +++ b/docs/vision.md @@ -1,6 +1,6 @@ -# Vision Brief: Form Submission MVP +# Vision brief: form submission MVP -## 1) Vision Statement +## 1) Vision statement To create a system that allows users to e-file online. Integrate with EFSP REST API. Allow non-technical users to configure workflows that make the e-file process more understandable and efficient. @@ -9,7 +9,7 @@ Allow non-technical users to configure workflows that make the e-file process mo * fill order/flow * field labeling/naming/mapping -## 2) Core Concepts +## 2) Core concepts Form Blocks & Filing Flows Form Blocks — reusable UI components (single field or grouped fields) that collect validated data; appearance is configurable. These are building blocks that don't mean much on their own but that can be pieced together. @@ -23,21 +23,21 @@ The system uses Form Blocks and Filing Flows: - Filing Flows: configured sequences of Form Blocks with branching, helper text, and a mapping to EFSP payloads. It can be helpful to think of these are "recipes" for guiding a pro se filer through the process of submitting a filing. A curated Filing Flow may be presented as a "Guided Interview" for a specific filing. This enables non‑technical users to assemble court‑ready experiences from reliable pieces, while experts can use a flexible workbench mode when needed. -## 3) Problem & Why Now +## 3) Problem & why now E‑filing is often confusing: fragmented portals, jargon‑heavy flows, and brittle forms. Non‑technical staff and self‑represented litigants struggle to submit complete, correct filings on the first try. A small, focused MVP using EFSP's REST APIs to integrate with Tyler can prove that a configuration-driven flow approach reduces errors and speeds up filings. We should be able to identify any sharp edges and gaps where improvements or additional features in the MVP's dependencies could help. -## 4) Target Audience +## 4) Target audience There are two target audiences for this MVP: • Self‑represented litigants, who are the end users of the filing process. • Non-technical personnel who author and maintain Filing Flows. -## 5) Goals & Success Signals +## 5) Goals & success signals • Reduce time‑to‑submit: first filing completed within 15 minutes for a defined recipe. • Increase first‑pass acceptance: ≥80% of guided submissions accepted without correction for IL — Adult Name Change in Cook County — measured on the MVP happy‑path constraints listed below. • Make configuration self‑serve: a non‑technical user can create or edit a Filing Flow without code. • Fast onboarding: new environment up and running via Docker/Compose with a few dependencies, compared to much slower roll-out and heavy dependency trees for other existing e-filing solutions. -## 6) Ideal MVP Feature Set +## 6) Ideal MVP feature set • EFSP REST API integration for authentication, options discovery, and submitting a minimal case/document package. • Form Blocks: a small set of validated input blocks (text, select, date, address) with basic theming. • Filing Flow runner: linear flow with optional simple branching; custom instructions and help text per step. @@ -51,7 +51,7 @@ There are two target audiences for this MVP: • Each filing includes one or more attachments (PDFs with form fields pre‑filled by the user outside the app). • Happy‑path constraints (MVP acceptance applies to this scope): Cook County Adult Name Change; no existing Tyler/EFSP account; no fee waiver; no impoundment. -## 7) Non‑Goals +## 7) Non‑goals • Full visual form builder or drag‑and‑drop editor. • Advanced RBAC, multi‑tenant billing, or complex approvals. • Deep analytics, custom dashboards, or BI. @@ -61,17 +61,17 @@ There are two target audiences for this MVP: • Extracting or cross-checking data from filled PDFs. • Advanced scripting or rules engine support in the Filing Flow. -## 8) User Journey Snapshot +## 8) User journey snapshot 1) User selects a Filing Flow (e.g., "Illinois — Adult Name Change"). 2) Guided steps present building blocks with plain‑language labels and helper text. 3) Data is validated inline; required PDFs (pre‑filled outside the app) are attached. 4) Review screen summarizes inputs in human‑readable form. 5) Submit via EFSP API; user sees confirmation and a link/reference number. -## 9) Value Proposition +## 9) Value proposition Clarity and speed over complexity. Filing Flows turn specialist knowledge into repeatable, guided experiences; Form Blocks ensure consistency and validation. Teams reduce training time and filing errors while keeping flexibility to evolve flows without code changes. -## 10) Risks & Assumptions +## 10) Risks & assumptions • EFSP API stability/coverage: assume required endpoints exist and are reliable. • Mapping correctness: field mappings must be accurate to avoid rejections. • Compliance and privacy: sensitive data must be handled and stored appropriately. @@ -79,50 +79,50 @@ Clarity and speed over complexity. Filing Flows turn specialist knowledge into r • Change management: Filing Flows remain understandable to non‑technical users. • Jurisdiction variability: county/court‑specific fields, document requirements, and payload formatting may require flow or mapping customization; we start with Cook County to limit scope. -## 11) Guiding Principles +## 11) Guiding principles • Clarity over control: plain language, minimal choices per step. • Small, composable pieces: prefer building blocks with single responsibility. • Human‑readable configuration: recipes are text‑based, diff‑able, and reviewable. • Secure by default: least‑privilege, avoid storing sensitive data unless required. • Observable: errors are logged with context; happy paths are measurable. -## 12) Error Handling Strategy +## 12) Error handling strategy The system handles errors at multiple levels to provide clear, actionable feedback: -### Validation Errors +### Validation errors • **Form Block validation**: Real-time validation with inline error messages for individual fields (e.g., "Phone number must be 10 digits"). • **Cross-field validation**: Step-level validation before proceeding (e.g., "End date must be after start date"). • **Document validation**: File type, size, and basic structure checks on upload. -### EFSP API Errors +### EFSP API errors • **Authentication failures**: Clear messaging with retry options and contact information. • **Submission rejections**: Parse EFSP error responses and map to user-friendly language with specific correction steps. • **Network/timeout errors**: Automatic retry with exponential backoff; clear status messaging to user. -### Error Recovery +### Error recovery • **Session persistence**: Form data preserved across errors and browser refreshes until successful submission or session expiry. • **Partial progress saving**: Users can return to incomplete filings within session timeframe. • **Error context**: Log errors with sufficient context for debugging while protecting PII. • **Graceful degradation**: If EFSP is unavailable, show status and estimated recovery time. -### User Experience +### User experience • **Progressive disclosure**: Show only relevant error details; provide "show more" for technical users. • **Action-oriented messaging**: "Fix this field" rather than "Invalid input". • **Error summary**: Collect and display all errors at form submission to avoid frustrating back-and-forth. -## 13) Data Retention & Privacy +## 13) Data retention & privacy • **Session data**: No persistent storage of user data beyond active session; all form data cleared on successful submission or session timeout. • **File storage**: Uploaded documents stored temporarily in secure external storage with automatic expiration in <24 hours (sufficient time for Tyler import). • **Audit logs**: Minimal logging of actions (submission attempts, errors) without PII; logs retained for debugging and metrics only. • **No user accounts**: Stateless design eliminates need for long-term data storage or user profile management. User profiles are created instead in Tyler's system and we pull from there. -## 14) Future Considerations +## 14) Future considerations • **Accessibility**: Target WCAG 2.1 AA compliance in future iterations for screen readers, keyboard navigation, and color contrast. • **Responsive design**: Mobile-optimized interface for tablet and phone usage, recognizing many users may not have desktop access. • **Multi-language support**: Spanish translation as priority for broader accessibility. • **Advanced error recovery**: Integration with court clerk systems for manual review of rejected filings. -## 15) Open Questions +## 15) Open questions • Expert mode: fully free‑form vs. semi‑guided based on live EFSP options? • Filing Flow format: JSON/YAML in‑repo vs. DB‑backed, and how to version changes? • Hosting: continue Docker/Compose for dev; what's the target for prod (e.g., container platform, DB)? @@ -136,7 +136,7 @@ The system handles errors at multiple levels to provide clear, actionable feedba • UI Component Libraries: the MVP will rely on vanilla Django w/ Javascript to limit the scope. However, there's a very big React ecosystem and it might make sense to leverage that in creating the reusable Form Blocks. Could also explore other UI frameworks/libraries within the Django universe like django-components (https://github.com/django-components/django-components) or djhtmx (https://github.com/iwanalabs/django-htmx-components) • Schemas: is it helpful or just friction to define schemas for the session data? Likely not useful but might help with any tooling we build later. -### Appendix: Possible Form Blocks +### Appendix: Possible form blocks - Person Name (first/middle/last, suffix; alias support) - Address (street, unit, city, state, ZIP; USPS normalization optional) - Email diff --git a/efile_app/efile/api/README.md b/efile_app/efile/api/README.md index 09dbe7a..a8aab92 100644 --- a/efile_app/efile/api/README.md +++ b/efile_app/efile/api/README.md @@ -1,4 +1,4 @@ -# API Documentation +# API documentation This directory contains the organized API endpoints for the Illinois eFile system. @@ -18,7 +18,7 @@ api/ └── urls.py # URL routing for all API endpoints ``` -## Base Classes +## Base classes ### APIResponseMixin Provides consistent response formatting for all API endpoints: @@ -29,7 +29,7 @@ Provides consistent response formatting for all API endpoints: - `get_auth_tokens(request)` - Retrieves auth tokens from session - `validate_request(request, required_params)` - Validates required parameters -## Endpoint Categories +## Endpoint categories ### Dropdown APIs (`/api/dropdowns/`) Cascading dropdown functionality with location-based prioritization and court-specific filtering: @@ -41,12 +41,12 @@ Cascading dropdown functionality with location-based prioritization and court-sp - `optional-services/` - Get optional services for case types - `party-types/` - Get available party types -### Form Configuration APIs (`/api/`) +### Form configuration APIs (`/api/`) Dynamic form configuration with court-specific conditional requirements: - `form-config/` - Get complete form configuration with court-specific modifications - `case-type-config/` - Get case type configuration mapping and keywords -### Suffolk LIT Lab Integration (`/api/suffolk/`) +### Suffolk LIT Lab integration (`/api/suffolk/`) Integration with external Suffolk LIT Lab eFile API: - `lookup-case/` - Case lookup functionality @@ -70,7 +70,7 @@ Filing creation and management: - `filings//update/` - Update filing - `filings//delete/` - Delete filing -## Usage Examples +## Usage examples ### Frontend JavaScript ```javascript diff --git a/efile_app/efile/static/config/README.md b/efile_app/efile/static/config/README.md index de6a019..b0503bd 100644 --- a/efile_app/efile/static/config/README.md +++ b/efile_app/efile/static/config/README.md @@ -1,19 +1,19 @@ -# Dynamic Case Form Configuration System +# Dynamic case form configuration system This document explains how the Illinois eFile system uses YAML-based configuration files to dynamically generate form fields and control the cascading dropdown behavior in the expert form. ## Table of Contents -1. [System Overview](#system-overview) -2. [Configuration Files](#configuration-files) -3. [How It Works](#how-it-works) -4. [API Integration](#api-integration) -5. [JavaScript Integration](#javascript-integration) -6. [Adding New Case Types](#adding-new-case-types) -7. [Court-Specific Customizations](#court-specific-customizations) +1. [System overview](#system-overview) +2. [Configuration files](#configuration-files) +3. [How it works](#how-it-works) +4. [Api integration](#api-integration) +5. [Javascript integration](#javascript-integration) +6. [Adding new case types](#adding-new-case-types) +7. [Court-specific customizations](#court-specific-customizations) 8. [Examples](#examples) -## System Overview +## System overview The configuration system provides a flexible, jurisdiction-aware approach to form generation that: @@ -27,9 +27,9 @@ The configuration system provides a flexible, jurisdiction-aware approach to for User Selections → API Calls → YAML Config → Dynamic Form Fields → JavaScript Rendering ``` -## Configuration Files +## Configuration files -### File Structure +### File structure ``` efile/static/config/ @@ -40,7 +40,7 @@ efile/static/config/ └── massachusetts.yaml # Massachusetts-specific overrides ``` -### Configuration Hierarchy +### Configuration file hierarchy 1. **Base Configuration** (`base-case-types.yaml`) - Defines common case types and field structures @@ -58,9 +58,9 @@ efile/static/config/ - State configurations override base when conflicts exist - Court-specific rules further customize the merged configuration -## How It Works +## How it works -### 1. User Interaction Flow +### 1. User interaction flow ```mermaid graph TD @@ -73,7 +73,7 @@ graph TD G --> H[Show/Hide Conditional Fields] ``` -### 2. Configuration Loading Process +### 2. Configuration loading process #### Step 1: Dropdown Selection When a user makes selections in the cascading dropdowns: @@ -97,7 +97,7 @@ def get_form_config(request): case_config = CaseFormAPIViews._find_case_type_config(case_type_id, jurisdiction) ``` -#### Step 3: Configuration Merging +#### Step 3: Configuration merging ```python # api/case_form_views.py def _load_jurisdiction_configuration(jurisdiction='illinois'): @@ -115,9 +115,9 @@ sections = _apply_court_specific_config(sections, court_code, case_type_key, jur #### Step 5: Form Rendering The merged configuration is returned as JSON and rendered by JavaScript. -## API Integration +## Api integration -### Key API Endpoints +### Key Api endpoints 1. **Form Configuration**: `/api/form-config/` ``` @@ -132,7 +132,7 @@ The merged configuration is returned as JSON and rendered by JavaScript. 3. **Party Types**: `/api/dropdowns/party-types/` -### API Response Structure +### Api response structure ```json { @@ -164,9 +164,9 @@ The merged configuration is returned as JSON and rendered by JavaScript. } ``` -## JavaScript Integration +## Javascript integration -### Core Components +### Core components 1. **CascadingDropdowns** (`cascading-dropdowns.js`) - Handles dropdown interactions @@ -178,7 +178,7 @@ The merged configuration is returned as JSON and rendered by JavaScript. - Creates HTML form elements - Applies conditional field logic -### Key JavaScript Methods +### Key Javascript methods ```javascript class CascadingDropdowns { @@ -197,7 +197,7 @@ class CascadingDropdowns { } ``` -## Adding New Case Types +## Adding new case types ### 1. Add to Base Configuration @@ -252,9 +252,9 @@ court_specific_requirements: required_for_courts: ["court:code"] ``` -## Court-Specific Customizations +## Court-specific customizations -### Use Cases +### Use cases 1. **Field Requirements**: Some courts require additional fields 2. **Field Hiding**: Some courts don't need certain sections @@ -301,7 +301,7 @@ court_specific_requirements: ## Examples -### Name Change Configuration +### Name change configuration **Base Configuration** (`base-case-types.yaml`): ```yaml @@ -395,7 +395,7 @@ The system generates a form with: - Illinois validation (no special characters) - Cook County requirement (Name Sought section becomes required) -## Configuration Schema Reference +## Configuration schema reference ### Supported Case Types @@ -409,7 +409,7 @@ Currently supported case type: **Note**: Other case types (divorce, order of protection, eviction/repossession) are defined in the YAML files but not currently active in the production system. -### Court-Based Conditional Logic +### Court-based conditional logic The system implements court-based conditional requirements for fine-grained control over section visibility: @@ -428,7 +428,7 @@ conditional_requirements: - **Court code matching**: Exact court code matching (e.g., "bond" matches configuration for "bond") - **Fallback logic**: Sections show by default unless explicitly hidden -### Field-Level Conditional Display (Planned) +### Field-level conditional display (Planned) Field-level conditional display is documented but not yet fully implemented: @@ -441,7 +441,7 @@ conditional_display: This feature is planned for future implementation when additional case types are activated. -### Field Types +### Field types ```yaml # Text input @@ -480,14 +480,14 @@ This feature is planned for future implementation when additional case types are optional_for_counties: ["lake", "will"] ``` -### Column Width Options +### Column width options - `col-12`: Full width - `col-6`: Half width - `col-4`: One-third width - `col-8`: Two-thirds width -### Validation Rules +### Validation rules ```yaml validation_rules: @@ -511,11 +511,11 @@ validation_rules: -### Keyword Matching Logic +### Keyword matching logic The system uses intelligent keyword matching to determine which configuration to use: -#### Example Keywords and Matches: +#### Example keywords and matches: ```yaml # Name change case type (currently supported) keywords: ["name change", "name petition", "change of name"] @@ -526,28 +526,28 @@ keywords: ["name change", "name petition", "change of name"] # Matches: Suffolk case types containing these keywords ``` -#### Matching Logic: +#### Matching logic: 1. **Exact match**: "name change" exactly matches "name change" 2. **Substring (keyword in case type)**: "name change" matches "Name Change Petition" 3. **Substring (case type in keyword)**: "change of name" matches "Legal Name Change" -### Debug Tips +### Debug tips 1. **Check browser console** for JavaScript errors 2. **Inspect API responses** in browser developer tools 3. **Verify YAML syntax** using online validators 4. **Check Django logs** for configuration loading errors -### Testing Configuration Changes +### Testing configuration changes 1. Restart Django server to reload YAML files 2. Clear browser cache to refresh JavaScript 3. Test with different court and case type combinations 4. Verify field visibility and requirements work as expected -## Current Implementation Status +## Current implementation status -### ✅ Fully Implemented Features +### ✅ Fully implemented features - **Base case type inheritance**: States extend base configurations - **Court-specific conditional requirements**: Fields can be required/hidden based on court selection - **Dynamic form generation**: YAML configurations converted to HTML forms @@ -558,20 +558,20 @@ keywords: ["name change", "name petition", "change of name"] - **Dynamic section visibility**: Sections and headers automatically hide when no content is rendered - **Court-specific field modifications**: Granular control over field visibility per court -### ⚠️ Partially Implemented Features +### ⚠️ Partially implemented features - **Field-level conditional display**: Structure documented but JavaScript implementation pending - `show_when_field`/`show_when_value` logic not yet active - Massachusetts config shows intended structure - Court-based conditional logic works as alternative -### 📋 Configuration Coverage +### 📋 Configuration coverage - **Name Change**: ✅ Base + Illinois implementation with court-specific variations - Cook County: Both sections required and visible - Bond Court: Both sections hidden (demonstrates section hiding functionality) - Other courts: Petitioner visible, Name Sought hidden by default - **Other Case Types**: ⚠️ Defined in YAML files but not active in production system -### 🔧 Development Notes +### 🔧 Development notes - **Field conditional display**: Requires JavaScript enhancement in `dynamic-form-sections.js` when additional case types are implemented - **Additional case types**: Available in YAML but not enabled for production use - **Court customizations**: Working system demonstrated with Cook County name change variations diff --git a/efile_app/efile/static/config/base-case-types.yaml b/efile_app/efile/static/config/base-case-types.yaml index 8388c8c..324f547 100644 --- a/efile_app/efile/static/config/base-case-types.yaml +++ b/efile_app/efile/static/config/base-case-types.yaml @@ -5,7 +5,7 @@ defaults: sections: parties: - title: "Required Parties" + title: "Required parties" show if: var: required_party_types.length op: gt @@ -13,7 +13,7 @@ defaults: api_endpoint: "/api/dropdowns/party-types/" requires_params: ["court", "case_type"] fields: - - section_title: "The Other Side" + - section_title: "The other side" required: true conditional_requirements: # Default: show for all courts except those explicitly hidden @@ -34,7 +34,7 @@ defaults: type: "text" required: true column_width: "col-6" - - section_title: "Their Physical Address" + - section_title: "Their physical address" required: true conditional_requirements: # Default: show for all courts except those explicitly hidden @@ -64,7 +64,7 @@ defaults: type: "text" required: true column_width: "col-6" - - section_title: "Their Contact Information" + - section_title: "Their contact information" required: true conditional_requirements: # Default: show for all courts except those explicitly hidden @@ -88,11 +88,11 @@ base_case_types: description: "Legal name change proceedings" sections: parties: - title: "Required Parties" + title: "Required parties" api_endpoint: "/api/dropdowns/party-types/" requires_params: ["court", "case_type"] fields: - - section_title: "Name Sought" + - section_title: "Name sought" required: false conditional_requirements: # Default: hidden for all courts except those explicitly required @@ -121,7 +121,7 @@ base_case_types: description: "Legal dissolution of marriage proceedings" sections: parties: - title: "Required Parties" + title: "Required parties" api_endpoint: "/api/dropdowns/party-types/" requires_params: ["court", "case_type"] fields: @@ -169,9 +169,9 @@ base_case_types: # description: "Eviction, repossession, and property restoration proceedings" # sections: # case_information: - # title: "Case Information" + # title: "Case information" # fields: - # - section_title: "Case Details" + # - section_title: "Case details" # required: true # fields: # - name: "case_number" @@ -188,7 +188,7 @@ base_case_types: # column_width: "col-6" # placeholder: "Additional case type information" # parties: - # title: "Required Parties" + # title: "Required parties" # api_endpoint: "/api/dropdowns/party-types/" # requires_params: ["court", "case_type"] # fields: diff --git a/efile_app/efile/static/config/states/illinois.yaml b/efile_app/efile/static/config/states/illinois.yaml index cfdd041..4746eca 100644 --- a/efile_app/efile/static/config/states/illinois.yaml +++ b/efile_app/efile/static/config/states/illinois.yaml @@ -82,7 +82,7 @@ court_specific_requirements: modifications: conditional_requirements: required_for_courts: ["cook:cd1"] - - field_group: "Name Sought" + - field_group: "Name sought" modifications: conditional_requirements: required_for_courts: ["cook:cd1"] @@ -96,7 +96,7 @@ court_specific_requirements: modifications: conditional_requirements: hidden_for_courts: ["bond"] - - field_group: "Name Sought" + - field_group: "Name sought" modifications: conditional_requirements: hidden_for_courts: ["bond"] \ No newline at end of file diff --git a/efile_app/efile/static/config/states/massachusetts.yaml b/efile_app/efile/static/config/states/massachusetts.yaml index 2fb9fe5..82dad89 100644 --- a/efile_app/efile/static/config/states/massachusetts.yaml +++ b/efile_app/efile/static/config/states/massachusetts.yaml @@ -42,13 +42,13 @@ case_types: # Override with Massachusetts terminology sections: parties: - title: "Parties to the Petition" # Massachusetts uses "petition" terminology + title: "Parties to the petition" # Massachusetts uses "petition" terminology sections: - section_title: "Petitioner" # Massachusetts uses different party type codes party_type_filter: ["MA_5628"] # Massachusetts petitioner code - - section_title: "Requested Name" # Different terminology + - section_title: "Requested name" # Different terminology required: true # Always required in Massachusetts party_type_filter: ["MA_56354"] # Massachusetts name sought code fields: @@ -78,7 +78,7 @@ case_types: # Massachusetts-specific additional sections additional_sections: background_check: - title: "Criminal Background Information" + title: "Criminal background information" required: true fields: - name: "criminal_background_check" diff --git a/efile_app/efile/static/js/README.md b/efile_app/efile/static/js/README.md index 44eb521..40e587c 100644 --- a/efile_app/efile/static/js/README.md +++ b/efile_app/efile/static/js/README.md @@ -1,8 +1,8 @@ -# Expert Form JavaScript Architecture +# Expert form JavaScript architecture This document describes the modular JavaScript architecture for the expert form functionality with dynamic court-specific form rendering. -## File Structure +## File structure ``` efile/static/js/ @@ -19,7 +19,7 @@ efile/static/config/ └── illinois.yaml # Illinois-specific court requirements and overrides ``` -## Module Overview +## Module overview ### 1. api-utils.js **Purpose**: Centralized API communication with error handling and CSRF protection. @@ -94,7 +94,7 @@ efile/static/config/ - `window.ExpertForm` (class) - `window.getExpertFormInstance()` (active instance) -## Loading Order +## Loading order The scripts must be loaded in this specific order due to dependencies: @@ -104,7 +104,7 @@ The scripts must be loaded in this specific order due to dependencies: 4. `dynamic-form-sections.js` - Independent, integrates with cascading dropdowns 5. `expert-form-main.js` - Coordinates all modules -## API Endpoints Used +## API endpoints used - `/api/auth/profile/` - User profile and location data - `/api/dropdowns/courts/` - Court listings with location prioritization @@ -114,9 +114,9 @@ The scripts must be loaded in this specific order due to dependencies: - `/api/dropdowns/document-types/` - Document types for final selection - `/api/form-config/` - Dynamic form configuration with court-specific conditional requirements -## Configuration System +## Configuration system -### YAML-Based Form Configuration +### YAML-based form configuration The system uses a hierarchical YAML configuration structure: **Base Configuration (`base-case-types.yaml`)**: @@ -131,7 +131,7 @@ The system uses a hierarchical YAML configuration structure: - `required_for_courts: ["cook:cd1"]` - Make sections required for specific courts - Supports inheritance from base templates with custom overrides -### Court-Specific Conditional Logic +### Court-specific conditional logic ```yaml # Example: Hide petitioner section for Bond County court_specific_requirements: @@ -147,7 +147,7 @@ court_specific_requirements: ## Configuration -### Location Intelligence +### Location intelligence The system automatically prioritizes courts based on user location: - User's zip code → county mapping - County → court prioritization @@ -155,30 +155,30 @@ The system automatically prioritizes courts based on user location: - Green recommendation notices positioned above dropdown labels - Notices persist during automatic cascading operations -### Court-Specific Form Rendering +### Court-specific form rendering - Dynamic form sections based on court selection - Conditional field visibility (hidden_for_courts, required_for_courts) - Automatic header management (hides "Parties" header when no sections render) - Real-time form updates when court selection changes - Form data preservation during court transitions -### Draft Saving +### Draft saving - Manual save only via "Save Draft" button (auto-save removed) - User-controlled draft creation for better user experience - Restoration on page reload (24-hour expiry) - localStorage backup for reliability - Visual feedback when saving drafts -### Error Handling +### Error handling - Network timeouts (30 seconds) - API error translation to user-friendly messages - Graceful degradation when APIs are unavailable - Console logging for debugging - Court-specific configuration validation -## Usage Examples +## Usage examples -### Accessing the Form Instance +### Accessing the form instance ```javascript const formInstance = getExpertFormInstance(); const dropdowns = formInstance.getCascadingDropdowns(); @@ -186,7 +186,7 @@ const validation = formInstance.getFormValidation(); const dynamicSections = formInstance.getDynamicFormSections(); ``` -### Manual API Calls +### Manual API calls ```javascript // Using the global API utility const response = await apiUtils.get('/api/dropdowns/courts/', { @@ -201,13 +201,13 @@ const formConfig = await apiUtils.get('/api/form-config/', { }); ``` -### Custom Validation +### Custom validation ```javascript const validation = getExpertFormInstance().getFormValidation(); validation.showNotification('Custom message', 'success'); ``` -### Court-Specific Configuration Examples +### Court-specific configuration examples ```javascript // Check if a section should show for current court const dynamicSections = getExpertFormInstance().getDynamicFormSections(); @@ -217,7 +217,7 @@ const shouldShow = dynamicSections.shouldShowSection(sectionConfig, 'bond'); dynamicSections.handleCaseTypeChange(); ``` -## Performance Considerations +## Performance considerations - Scripts load asynchronously after DOM ready - API requests are cached where appropriate @@ -226,7 +226,7 @@ dynamicSections.handleCaseTypeChange(); - Court-specific form configurations are cached to reduce API calls - Dynamic form sections only re-render when necessary (court or case type changes) -## Security Features +## Security features - CSRF token automatic inclusion - XSS prevention through proper DOM manipulation @@ -251,7 +251,7 @@ This will provide detailed logging for: ## Troubleshooting -### Debug Commands +### Debug commands ```javascript // Check current form configuration console.log(getExpertFormInstance().getDynamicFormSections().config); diff --git a/efile_app/efile/static/js/cascading-dropdowns.js b/efile_app/efile/static/js/cascading-dropdowns.js index 91548b3..f2e0d60 100644 --- a/efile_app/efile/static/js/cascading-dropdowns.js +++ b/efile_app/efile/static/js/cascading-dropdowns.js @@ -643,7 +643,7 @@ class CascadingDropdowns { } servicesContainer.innerHTML = ` -
Optional Services
+
Optional services
diff --git a/efile_app/efile/static/js/dynamic-form-sections.js b/efile_app/efile/static/js/dynamic-form-sections.js index 88b223f..e540998 100644 --- a/efile_app/efile/static/js/dynamic-form-sections.js +++ b/efile_app/efile/static/js/dynamic-form-sections.js @@ -440,7 +440,7 @@ class DynamicFormSections { // Create header and container for case information const header = document.createElement("h3"); header.className = "subsection-header"; - header.textContent = sectionConfig.title || getText("Case Information"); + header.textContent = sectionConfig.title || getText("Case information"); const containerDiv = document.createElement("div"); containerDiv.id = "caseInfoContainer"; @@ -458,7 +458,7 @@ class DynamicFormSections { // Create header and container for parties const header = document.createElement("h3"); header.className = "subsection-header"; - header.textContent = sectionConfig.title || getText("Required Parties"); + header.textContent = sectionConfig.title || getText("Required parties"); const containerDiv = document.createElement("div"); containerDiv.id = "partiesContainer"; diff --git a/efile_app/efile/static/js/review.js b/efile_app/efile/static/js/review.js index 24d6938..7b4052d 100644 --- a/efile_app/efile/static/js/review.js +++ b/efile_app/efile/static/js/review.js @@ -335,12 +335,12 @@ const UIUpdater = { const docName = uploadData.files.lead.name.includes("Name Change") ? "Name Change Form" : "Lead Document"; html += this.createDocumentHTML(docName, uploadData.files.lead.name, 'lead', true); } else { - html += `
1. Lead Document (required)
No document found
`; + html += `
1. Lead document (required)
No document found
`; } // Supporting documents if (uploadData.files?.supporting?.length > 0) { - html += '
2. Fee Waiver (optional)
File or Files
'; + html += '
2. Fee waiver (optional)
File or Files
'; uploadData.files.supporting.forEach(file => { html += `
diff --git a/efile_app/efile/templates/efile/components/profile_header.html b/efile_app/efile/templates/efile/components/profile_header.html index e01d627..38a7a1d 100644 --- a/efile_app/efile/templates/efile/components/profile_header.html +++ b/efile_app/efile/templates/efile/components/profile_header.html @@ -28,7 +28,7 @@
{% if is_logged_in %}
- +
-

{% translate "Filing Submitted Successfully!" %}

+

{% translate "Filing submitted successfully!" %}

{{ success_message }}
diff --git a/efile_app/efile/templates/efile/expert_form.html b/efile_app/efile/templates/efile/expert_form.html index 690eca7..b7dda77 100644 --- a/efile_app/efile/templates/efile/expert_form.html +++ b/efile_app/efile/templates/efile/expert_form.html @@ -19,7 +19,7 @@
{% csrf_token %} -

{% translate "Case Information" %}

+

{% translate "Case information" %}

{% translate "Please provide the basic information about your case. Required fields are marked with a red asterisk" %} (*). @@ -133,7 +133,7 @@

{% translate "Case type" %}