feat: Allow creating budgets up to 2 years ahead

[grrtt49]

Summary

This PR updates the budget date constraint so users can create budgets for future periods (up to 2 years ahead), instead of being limited to the current month. Closes #270)

What changed

• Before: maximum budget creating date was capped at the current month.
• After: maximum budget creating date is capped at today + 2 years.
• Keeps existing validation behavior intact (same error handling/UI messaging), only expands the allowed upper bound.

Why

Users commonly plan budgets ahead of time; restricting creation to only the current month blocks forward planning.

Summary by CodeRabbit

• Refactor

  • Improved budget date validation logic with enhanced support for future budget dates (up to 2 years ahead) and custom month-start schedules.

• Tests

  • Expanded test coverage for budget scenarios, including future date limits and custom month-start configuration validations.

[coderabbitai]

📝 Walkthrough

Walkthrough

The changes refactor budget date validation logic in the Budget model by introducing a new latest_valid_budget_start_date helper method to enforce a 2-year forward-looking boundary, modifying the budget_date_valid? validation, and adjusting next_budget_param to compute and validate the next date before returning it. Test coverage is expanded to validate these new constraints across standard and custom month-start scenarios.

Changes

Cohort / File(s)	Summary
Budget Model Refactoring app/models/budget.rb	Refactored budget_date_valid? to compute budget start conditionally (custom month start vs. beginning of month), added latest_valid_budget_start_date private helper to enforce 2-year upper bound, and modified next_budget_param to allow validation and return of computed next dates.
Budget Test Coverage test/models/budget_test.rb	Expanded test suite for budget_date_valid? covering future date allowances up to 2 years (standard and custom month-start), rejection beyond 2 years, and new tests for next_budget_param behavior at current and future cap boundaries.

Estimated code review effort

🎯 3 (Moderate) | ⏱️ ~22 minutes

Poem

🐰 With whiskers twitching, I hop with cheer,
Two years of budgets, now crystal clear!
New bounds and helpers, validation bright,
The rabbit's refactor sets it all right! 🎉

🚥 Pre-merge checks | ✅ 2 | ❌ 1

❌ Failed checks (1 warning)

Check name	Status	Explanation	Resolution
Docstring Coverage	⚠️ Warning	Docstring coverage is 0.00% which is insufficient. The required threshold is 80.00%.	Write docstrings for the functions missing them to satisfy the coverage threshold.

✅ Passed checks (2 passed)

Check name	Status	Explanation
Description Check	✅ Passed	Check skipped - CodeRabbit’s high-level summary is enabled.
Title check	✅ Passed	The title clearly and concisely summarizes the main change: extending budget creation to allow dates up to 2 years in advance, which aligns with the refactored validation logic and test expansions in the changeset.

_{✏️ Tip: You can configure your own custom pre-merge checks in the settings.}

✨ Finishing touches

• 📝 Generate docstrings

🧪 Generate unit tests (beta)

• Create PR with unit tests
• Post copyable unit tests in a comment

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands and usage tips.}

[jjmata]

Usability-wise: how does this work when the user changes their mind and wants to start spending more/less on a category? I'm guessing this is one of the reasons it was left the way it is. 🤔

[jjmata]

Usability-wise: how does this work when the user changes their mind and wants to start spending more/less on a category? I'm guessing this is one of the reasons it was left the way it is. 🤔

As I ponder that use case, would say my expectation is that the budget for all future months should be updated to reflect the new numbers EXCEPT in those places where edits had already been made. That's the "corner case" where things get interesting.

[grrtt49]

Usability-wise: how does this work when the user changes their mind and wants to start spending more/less on a category? I'm guessing this is one of the reasons it was left the way it is. 🤔

As I ponder that use case, would say my expectation is that the budget for all future months should be updated to reflect the new numbers EXCEPT in those places where edits had already been made. That's the "corner case" where things get interesting.

Right now, it works just like any other month in the past/current. You can choose to create a budget for that month, if you do, you are able to set how much expected income and budgeted spending you want, then you can set the amounts for each category. They are initialized at 0 for each, just as it would be for any past/current month. And after creation, the numbers for each month are able to be edited like any past/current month.
For me personally, I would not want any numbers carrying over from a previous budget, as I might plan for a little more/less spending in each category based on what is happening that month.
If we wanted to have numbers carry over from month to month for a budget, I think it might be better in a separate feature. But let me know your thoughts or if I misunderstood anything!

[grrtt49]

@jjmata Could you let me know if this makes sense, or is there anything I'm not understanding?