* Add budget rollover: copy from previous month
When navigating to an uninitialized budget month, show a prompt
offering to copy amounts from the most recent initialized budget.
Copies budgeted_spending, expected_income, and all matching category
allocations. Also fixes over-allocation warning showing on uninitialized
budgets.
Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
* Redirect copy_previous to categories wizard for review
Matches the normal budget setup flow (edit → categories → show)
so users can review/tweak copied allocations before confirming.
Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
* Address code review: eager-load categories, guard against overwrite
- Add .includes(:budget_categories) to most_recent_initialized_budget
to avoid N+1 when copy_from! iterates source categories
- Guard copy_previous action against overwriting already-initialized
budgets (prevents crafted POST from clobbering existing data)
- Add i18n key for already_initialized flash message
Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
* Add invariant guards to copy_from! for defensive safety
Validate that source budget belongs to the same family and precedes
the target budget before copying. Protects against misuse from
other callers beyond the controller.
Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
* Fix button overflow on small screens in copy previous prompt
Stack buttons vertically on mobile, side-by-side on sm+ breakpoint.
Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
---------
Co-authored-by: Claude Opus 4.6 <noreply@anthropic.com>
* Add customizable budget month start day (#253)
Allow users to set a custom month-to-date start date (1st-28th) for
budgeting and MTD calculations. Useful for users who want budget
periods aligned with their pay schedule (e.g., 25th to 24th).
Changes:
- Add month_start_day column to families table (default: 1)
- Add database check constraint for valid range (1-28)
- Add Family#uses_custom_month_start?, custom_month_start_for,
custom_month_end_for, current_custom_month_period helper methods
- Add Period.current_month_for(family), last_month_for(family) methods
- Update Budget model for custom month boundaries in find_or_bootstrap,
param_to_date, budget_date_valid?, current?, and name methods
- Add month_start_day setting to Settings > Preferences UI
- Add warning message when custom month start day is configured
- Add comprehensive tests with travel_to for date robustness
Fixes#253
* Add /api/v1/user endpoint for Flutter mobile app and PWA
Expose user preferences including month_start_day via API endpoint
following existing pattern for default_period. This allows Flutter
mobile app and PWA to read/update user preferences through a
consistent API contract.
Endpoints:
- GET /api/v1/user - Read user preferences including family settings
- PATCH /api/v1/user - Update user preferences
Response includes: id, email, first_name, last_name, default_period,
locale, and family settings (currency, timezone, date_format, country,
month_start_day).
* Update Periodable to use family-aware MTD periods
When users select 'current_month' or 'last_month' period filters on
dashboard/reports, now respects the family's custom month_start_day
setting instead of using static calendar month boundaries.
This ensures MTD filter on dashboard is consistent with how budgets
calculate their periods when custom month start day is configured.
* Fix param_to_date to correctly map budget params to custom periods
When a family uses a custom start day, the previous implementation
called custom_month_start_for on the 1st of the month, which incorrectly
shifted dates before the start day to the previous month.
Now we directly construct the date using family.month_start_day, so
'jan-2026' with month_start_day=25 correctly returns Jan 25, 2026
instead of Dec 25, 2025.
* Fix param_to_date and use Current pattern in API controller
- Fix param_to_date to directly construct date with family.month_start_day
instead of using custom_month_start_for which incorrectly shifted dates
- Replace current_user with Current.user/Current.family in API controller
to follow project convention used in other API v1 controllers
* Add i18n for budget name method
Use I18n.t for localizable budget period names to follow
project conventions for user-facing strings.
* Remove unused budget_end variable in budget_date_valid?
* Use Date.current for timezone consistency in Budget#current?
* Address PR review feedback
- Remove API users endpoint (mobile won't use yet)
- Remove user route from config/routes.rb
- Remove ai_summary/document_type schema bleed from pdf-import-ai branch
* Pass family to param_to_date for custom month logic
* Run migration to add month_start_day column to schema
* Schema regressions
---------
Co-authored-by: mkdev11 <jaysmth689+github@users.noreply.github.com>
Co-authored-by: Juan José Mata <juanjo.mata@gmail.com>
* Add breadcrumbs support across application
Fixes#1896
* Potential fix for tests
* Simplify breadcrumbs implementation
Remove complex breadcrumbs logic from controllers and concern, replacing with a simpler default approach that sets a basic breadcrumb based on the current controller name
* Refactor page header and breadcrumbs rendering
Remove complex breadcrumbs helper method and update layout to use more flexible content_for approach for page headers and breadcrumbs
* Add fallback breadcrumbs rendering to settings layout
Since the very first 0.1.0-alpha.1 release, we've been moving quickly to add new features to the Maybe app. In doing so, some parts of the codebase have become outdated, unnecessary, or overly-complex as a natural result of this feature prioritization.
Now that "core" Maybe is complete, we're moving into a second phase of development where we'll be working hard to improve the accuracy of existing features and build additional features on top of "core". This PR is a quick overhaul of the existing codebase aimed to:
- Establish the brand new and simplified dashboard view (pictured above)
- Establish and move towards the conventions introduced in Cursor rules and project design overview #1788
- Consolidate layouts and improve the performance of layout queries
- Organize the core models of the Maybe domain (i.e. Account::Entry, Account::Transaction, etc.) and break out specific traits of each model into dedicated concerns for better readability
- Remove stale / dead code from codebase
- Remove overly complex code paths in favor of simpler ones
