- Modified the GitHub Actions workflow to streamline the deployment process by installing Docker directly and using shell commands for building and pushing images.
- Changed the base image for the backend Dockerfile from `python:3.11-slim` to `python:alpine` for a smaller footprint.
- Updated the frontend Dockerfile to use `node:23-alpine` instead of `node:24-alpine`, and refactored the production stage to use `node:slim`. Added a script for runtime environment variable injection.
- Removed redundant form elements and improved the layout for better readability.
- Streamlined the chore creation and editing process with enhanced validation and auto-save features.
- Updated keyboard shortcuts for improved accessibility and user experience.
- Enhanced modal interactions and improved loading states during data fetching.
- Cleaned up unused code and optimized the overall component structure.
This commit addresses issues with backend models, schemas, and migrations.
Key changes:
- Consolidated all SQLAlchemy model definitions into `be/app/models.py`.
- Emptied `be/app/models/expense.py` as its contents were duplicates.
- Verified and standardized Base class usage and SQLAlchemy imports in models.
- Confirmed the correctness of self-referential relationships in the `Expense` model.
- Added a clarifying comment to `SplitTypeEnum` regarding future extensibility.
- Corrected a typo in `Settlement.created_by_user_id`.
Migration Cleanup:
- Deleted all existing Alembic migration files from `be/alembic/versions/`.
- Created a new, single initial migration script (`0001_initial_schema.py`) that defines the entire database schema based on the current state of the SQLAlchemy models. This provides a clean slate for future migrations.
This reset was performed because the previous migration history was complex and contained a revision that was incompatible with the current model definitions. Starting fresh ensures consistency between the models and the database schema from the initial point.
Here's a breakdown of the changes:
1. **`AccountPage.vue`**:
* I replaced the main heading with `VHeading`.
* I updated the loading spinner to `VSpinner`.
* I converted the error alert to `VAlert` with an action button.
* I refactored the Profile, Password, and Notifications sections to use `VCard` for their structure.
* The form elements within these cards (name, email, passwords) now use `VFormField` and `VInput`.
* Action buttons like "Save Changes" and "Change Password" are now `VButton` with an integrated `VSpinner` for loading states.
* The notification preferences list uses `VList` and `VListItem`, with each preference toggle converted to `VToggleSwitch`.
2. **`GroupDetailPage.vue`**:
* I updated the page-level loading spinner, error alert, and main heading to `VSpinner`, `VAlert`, and `VHeading`.
* I refactored the "Group Members", "Invite Members", "Chores", and "Expenses" sections from custom "neo-card" styling to use `VCard`.
* Headers within these cards use `VHeading` and action buttons use `VButton` (I kept Material Icons where `VIcon` wasn't a direct replacement).
* Lists of members, chores, and expenses now use `VList` and `VListItem`.
* Buttons within list items (e.g., "Remove member") are `VButton` with `VSpinner`.
* Role indicators and frequency/split type "chips" are now `VBadge` components, and I updated the helper functions to return VBadge-compatible variants.
* The "Invite Members" form elements (input for code, copy button) use `VFormField`, `VInput`, and `VButton`.
* I simplified empty states within card bodies using `VIcon` and text.
3. **`ListDetailPage.vue`**: This complex page required several steps to refactor:
* **Page-Level & Header:** I updated the loading state to `VSpinner`, the error alert to `VAlert`, and the main title to `VHeading`. Header action buttons are `VButton` with icons, and the list status is `VBadge`.
* **Modals:** I converted all five custom modals (OCR, Confirmation, Edit Item, Settle Share, Cost Summary shell) to use `VModal`. Internal forms and actions within these modals now use `VFormField`, `VInput`, `VButton`, `VSpinner`, `VList`, `VListItem`, and `VAlert` as appropriate. I removed the `onClickOutside` logic.
* **Main Items List:** The loading state uses `VCard` with `VSpinner`, and the empty state uses `VCard variant="empty-state"`. The list itself is now a `VCard` containing a `VList`. Each item is a `VListItem` with internal content refactored to use `VCheckbox`, `VInput` (for price), and `VButton` with `VIcon` for actions.
* **Add Item Form:** I re-structured this below the items list, using `VFormField`, `VInput`, and `VButton` with `VIcon`.
* **Expenses Section:** The main card uses `VCard` with `VHeading` and `VButton` in the header. Loading/error/empty states use `VSpinner`, `VAlert`, `VIcon`. The expenses list is `VList`, with each expense item as a `VListItem`. Statuses are `VBadge`.
This refactoring significantly increases the usage of the Valerie UI component library across these key application pages. This should help create a more consistent experience for you and make development smoother. Next, I'll focus on the Chores-related pages.
This commit refactors parts of `GroupsPage.vue`, `ListsPage.vue`, and the shared `CreateListModal.vue` to use the newly created Valerie UI components.
Key changes include:
1. **Modals:**
* The "Create Group Dialog" in `GroupsPage.vue` now uses `VModal`, `VFormField`, `VInput`, `VButton`, and `VSpinner`.
* The `CreateListModal.vue` component (used by both pages) has been internally refactored to use `VModal`, `VFormField`, `VInput`, `VTextarea`, `VSelect`, `VButton`, and `VSpinner`.
2. **Forms:**
* The "Join Group" form in `GroupsPage.vue` now uses `VFormField`, `VInput`, `VButton`, and `VSpinner`.
3. **Alerts:**
* Error alerts in both `GroupsPage.vue` and `ListsPage.vue` now use the `VAlert` component, with retry buttons placed in the `actions` slot.
4. **Empty States:**
* The empty state displays (e.g., "No Groups Yet", "No lists found") in both pages now use the `VCard` component with `variant="empty-state"`, mapping content to the relevant props and slots.
5. **Buttons:**
* Various standalone buttons (e.g., "Create New Group", "Create New List", "List" button on group cards) have been updated to use the `VButton` component with appropriate props for variants, sizes, and icons.
**Scope of this Refactor:**
* The focus was on replacing direct usages of custom-styled modal dialogs, form elements, alerts, and buttons with their Valerie UI component counterparts.
* Highly custom card-like structures such as `neo-group-card` (in `GroupsPage.vue`) and `neo-list-card` (in `ListsPage.vue`), along with their specific "create" card variants, have been kept with their existing custom styling for this phase. This is due to their unique layouts and styling not directly mapping to the current generic `VCard` component without significant effort or potential introduction of overly specific props to `VCard`. Only buttons within these custom cards were refactored.
* The internal item rendering within `neo-list-card` (custom checkboxes, add item input) also remains custom for now.
This refactoring improves consistency by leveraging the standardized Valerie UI components for common UI patterns like modals, forms, alerts, and buttons on these pages.
I reviewed the backend codebase covering schema, API endpoints, error handling, and tests.
Key changes I implemented:
- Updated `app/models.py`:
- Added `parent_expense_id` and `last_occurrence` fields to the `Expense` model to align with the `add_recurring_expenses.py` migration.
- Added `parent_expense` and `child_expenses` self-referential relationships to the `Expense` model.
- Updated `app/core/exceptions.py`:
- Removed the unused and improperly defined `BalanceCalculationError` class.
I identified areas for future work:
- Create a new Alembic migration if necessary to ensure `parent_expense_id` and `last_occurrence` columns are correctly reflected in the database, or verify the existing `add_recurring_expenses.py` migration's status.
- Significantly improve API test coverage, particularly for:
- Chores module (personal and group)
- Groups, Invites, Lists, Items, OCR endpoints
- Full CRUD operations for Expenses and Settlements
- Recurring expense functionalities.
- Introduced a new `RecurrencePattern` model to manage recurrence details for expenses, allowing for daily, weekly, monthly, and yearly patterns.
- Updated the `Expense` model to include fields for recurrence management, such as `is_recurring`, `recurrence_pattern_id`, and `next_occurrence`.
- Modified the database schema to reflect these changes, including alterations to existing columns and the removal of obsolete fields.
- Enhanced the expense creation logic to accommodate recurring expenses and updated related CRUD operations accordingly.
- Implemented necessary migrations to ensure database integrity and support for the new features.
- Redesigned the ChoresPage layout to improve user experience, introducing a new header with tabs for viewing overdue, today, upcoming, all pending, and completed chores.
- Implemented a calendar view for better visualization of chores, allowing users to navigate between months and add chores directly on specific dates.
- Added a loading state to enhance feedback during data fetching.
- Introduced a shortcuts modal to display keyboard shortcuts for improved accessibility.
- Enhanced chore card interactions with improved styling and responsiveness, including a transition effect for list items.
- Updated chore management functionalities, including create, edit, and delete operations, with better validation and auto-save features.
- Modified the production deployment workflow to trigger on pushes to the 'prod' branch and updated Docker registry login to use Gitea Container Registry.
- Enhanced ListDetailPage.vue to improve loading states and error handling, introducing a new loading mechanism for items and utilizing session storage for cached data.
- Implemented Intersection Observer for pre-fetching list details to optimize user experience during navigation.
- Improved touch feedback for list cards and optimized styles for mobile responsiveness.
- Introduced `docker-compose.prod.yml` to define services for production deployment, including PostgreSQL, FastAPI backend, frontend, and Redis.
- Created `env.production.template` to outline necessary environment variables for production, ensuring sensitive data is not committed.
- Added `PRODUCTION.md` as a deployment guide detailing the setup process using Docker Compose and Gitea Actions for CI/CD.
- Implemented Gitea workflows for build, test, and deployment processes to streamline production updates.
- Updated backend and frontend Dockerfiles for optimized production builds and configurations.
- Enhanced application settings to support environment-specific configurations, including CORS and health checks.
- Added support for refresh tokens in the authentication backend, allowing users to obtain new access tokens using valid refresh tokens.
- Created a new `BearerResponseWithRefresh` model to structure responses containing both access and refresh tokens.
- Updated the `AuthenticationBackend` to handle login and logout processes with refresh token support.
- Introduced a new `/auth/jwt/refresh` endpoint to facilitate token refreshing, validating the refresh token and generating new tokens as needed.
- Modified OAuth callback logic to generate and return both access and refresh tokens upon successful authentication.
- Updated frontend API service to send the refresh token in the Authorization header for token refresh requests.
- Introduced a new `notes.md` file to document critical tasks and progress for stabilizing the core functionality of the MitList application.
- Documented the status and findings for key tasks, including backend financial logic fixes, frontend expense split settlement implementation, and core authentication flow reviews.
- Outlined remaining work for production deployment, including secret management, CI/CD pipeline setup, and performance optimizations.
- Updated the logging configuration to change the log level to WARNING for production readiness.
- Enhanced the database connection settings to disable SQL query logging in production.
- Added a new endpoint to list all chores for improved user experience and optimized database queries.
- Implemented various CRUD operations for chore assignments, including creation, retrieval, updating, and deletion.
- Updated frontend components and services to support new chore assignment features and improved error handling.
- Enhanced the expense management system with new fields and improved API interactions for better user experience.
- Introduced a new `RecurrencePattern` model to manage recurrence details for expenses, allowing for daily, weekly, monthly, and yearly patterns.
- Updated the `Expense` model to include fields for recurrence management, such as `is_recurring`, `recurrence_pattern_id`, and `next_occurrence`.
- Modified the database schema to reflect these changes, including alterations to existing columns and the removal of obsolete fields.
- Enhanced the expense creation logic to accommodate recurring expenses and updated related CRUD operations accordingly.
- Implemented necessary migrations to ensure database integrity and support for the new features.
I've refactored the group balance summary logic to correctly account for
SettlementActivity. A SettlementActivity now reduces your
effective total_share_of_expenses, ensuring that net balances within
a group sum to zero. Previously, SettlementActivity amounts were
incorrectly added to total_settlements_paid, skewing balance
calculations.
I updated the existing `test_group_balance_summary_with_settlement_activity`
to assert the corrected balance outcomes.
I also added an extensive suite of API-level tests for:
- All expense splitting types (EQUAL, EXACT_AMOUNTS, PERCENTAGE, SHARES, ITEM_BASED),
covering various scenarios and input validations.
- Group balance summary calculations, including multiple scenarios with
SettlementActivity, partial payments, multiple expenses, and
interactions with generic settlements. All balance tests verify that
the sum of net balances is zero.
The CRUD operations for expenses and settlement activities were reviewed
and found to be sound, requiring no changes for this fix.
This resolves the flawed logic identified in
`be/tests/api/v1/test_costs.py` (test_group_balance_summary_with_settlement_activity)
and ensures that backend financial calculations are provably correct.
- Added support for recurring expenses, allowing users to define recurrence patterns (daily, weekly, monthly, yearly) for expenses.
- Introduced `RecurrencePattern` model to manage recurrence details and linked it to the `Expense` model.
- Implemented background job scheduling using APScheduler to automatically generate new expenses based on defined patterns.
- Updated expense creation logic to handle recurring expenses, including validation and database interactions.
- Enhanced frontend components to allow users to create and manage recurring expenses through forms and lists.
- Updated documentation to reflect new features and usage guidelines for recurring expenses.
- Introduced CreateExpenseForm.vue for creating new expenses with fields for description, total amount, split type, and date.
- Integrated the CreateExpenseForm into ListDetailPage.vue, allowing users to add expenses directly from the list view.
- Enhanced UI with a modal for the expense creation form and added validation for required fields.
- Updated styles for consistency across the application.
- Implemented logic to refresh the expense list upon successful creation of a new expense.
Backend:
- Added `SettlementActivity` model to track payments against specific expense shares.
- Added `status` and `paid_at` to `ExpenseSplit` model.
- Added `overall_settlement_status` to `Expense` model.
- Implemented CRUD for `SettlementActivity`, including logic to update parent expense/split statuses.
- Updated `Expense` CRUD to initialize new status fields.
- Defined Pydantic schemas for `SettlementActivity` and updated `Expense/ExpenseSplit` schemas.
- Exposed API endpoints for creating/listing settlement activities and settling shares.
- Adjusted group balance summary logic to include settlement activities.
- Added comprehensive backend unit and API tests for new functionality.
Frontend (Foundation & TODOs due to my current capabilities):
- Created TypeScript interfaces for all new/updated models.
- Set up `listDetailStore.ts` with an action to handle `settleExpenseSplit` (API call is a placeholder) and refresh data.
- Created `SettleShareModal.vue` component for payment confirmation.
- Added unit tests for the new modal and store logic.
- Updated `ListDetailPage.vue` to display detailed expense/share statuses and settlement activities.
- `mitlist_doc.md` updated to reflect all backend changes and current frontend status.
- A `TODO.md` (implicitly within `mitlist_doc.md`'s new section) outlines necessary manual frontend integrations for `api.ts` and `ListDetailPage.vue` to complete the 'Settle Share' UI flow.
This set of changes provides the core backend infrastructure for precise expense share tracking and settlement, and lays the groundwork for full frontend integration.
This commit introduces a suite of unit and E2E tests for the Vue.js
frontend, significantly improving code coverage and reliability.
Unit Test Summary:
- Setup: Configured Vitest and @vue/test-utils.
- Core UI Components: Added tests for EssentialLink, SocialLoginButtons,
and NotificationDisplay.
- Pinia Stores: Implemented tests for auth, notifications, and offline
stores, including detailed testing of actions, getters, and state
management. Offline store tests were adapted to its event-driven design.
- Services:
- api.ts: Tested Axios client config, interceptors (auth token refresh),
and wrapper methods.
- choreService.ts & groupService.ts: Tested all existing service
functions for CRUD operations, mocking API interactions.
- Pages:
- AccountPage.vue: Tested rendering, data fetching, form submissions
(profile, password, preferences), and error handling.
- ChoresPage.vue: Tested rendering, chore display (personal & grouped),
CRUD modals, and state handling (loading, error, empty).
- LoginPage.vue: Verified existing comprehensive tests.
E2E Test (Playwright) Summary:
- Auth (`auth.spec.ts`):
- User signup, login, and logout flows.
- Logout test updated with correct UI selectors.
- Group Management (`groups.spec.ts`):
- User login handled via `beforeAll` and `storageState`.
- Create group and view group details.
- Update and Delete group tests are skipped as corresponding UI
functionality is not present in GroupDetailPage.vue.
- Selectors updated based on component code.
- List Management (`lists.spec.ts`):
- User login handled similarly.
- Create list (within a group), view list, add item to list,
and mark item as complete.
- Delete list test is skipped as corresponding UI functionality
is not present.
- Selectors based on component code.
This work establishes a strong testing foundation for the frontend.
Skipped E2E tests highlight areas where UI functionality for certain
CRUD operations (group update/delete, list delete) may need to be added
if desired.
This commit introduces a suite of unit tests for the Vue.js frontend,
significantly improving code coverage and reliability.
Key areas covered:
- **Setup**: Configured Vitest and @vue/test-utils.
- **Core UI Components**: Added tests for SocialLoginButtons and NotificationDisplay.
- **Pinia Stores**: Implemented tests for auth, notifications, and offline stores,
including detailed testing of actions, getters, and state management.
Offline store tests were adapted to its event-driven design.
- **Services**:
- `api.ts`: Tested Axios client config, interceptors (auth token refresh),
and wrapper methods.
- `choreService.ts` & `groupService.ts`: Tested all existing service
functions for CRUD operations, mocking API interactions.
- **Pages**:
- `AccountPage.vue`: Tested rendering, data fetching, form submissions
(profile, password, preferences), and error handling.
- `ChoresPage.vue`: Tested rendering, chore display (personal & grouped),
CRUD modals, and state handling (loading, error, empty).
- `LoginPage.vue`: Verified existing comprehensive tests.
These tests provide a solid foundation for frontend testing. The next planned
step is to enhance E2E tests using Playwright.
This commit introduces a comprehensive chore management system, allowing users to create, manage, and track both personal and group chores. Key changes include:
- Addition of new API endpoints for personal and group chores in `be/app/api/v1/endpoints/chores.py`.
- Implementation of chore models and schemas to support the new functionality in `be/app/models.py` and `be/app/schemas/chore.py`.
- Integration of chore services in the frontend to handle API interactions for chore management.
- Creation of new Vue components for displaying and managing chores, including `ChoresPage.vue` and `PersonalChoresPage.vue`.
- Updates to the router to include chore-related routes and navigation.
This feature enhances user collaboration and organization within shared living environments, aligning with the project's goal of streamlining household management.
I've implemented the foundational backend components for the chore management feature.
Key changes include:
- Definition of `Chore` and `ChoreAssignment` SQLAlchemy models in `be/app/models.py`.
- Addition of corresponding relationships to `User` and `Group` models.
- Creation of an Alembic migration script (`manual_0001_add_chore_tables.py`) for the new database tables. (Note: Migration not applied in sandbox).
- Implementation of a utility function `calculate_next_due_date` in `be/app/core/chore_utils.py` for determining chore due dates based on recurrence rules.
- Definition of Pydantic schemas (`ChoreCreate`, `ChorePublic`, `ChoreAssignmentCreate`, `ChoreAssignmentPublic`, etc.) in `be/app/schemas/chore.py` for API data validation.
- Implementation of CRUD operations (create, read, update, delete) for Chores in `be/app/crud/chore.py`.
This commit lays the groundwork for adding Chore Assignment CRUD operations and the API endpoints for both chores and their assignments.
Introduce a new technical specification for managing database transactions in FastAPI, ensuring ACID compliance through standardized practices. The specification outlines transaction handling for API endpoints, CRUD functions, and non-API operations, emphasizing the use of context managers and error handling.
Additionally, update the requirements file to include new testing dependencies for async operations, enhancing the testing framework for the application.
