Category improvements

[sokie]

• Updated default categories to a more inclusive set
• Updated default icon set for categories
• Updated default categories colors to better separate then.

Summary by CodeRabbit

• Updates
  • Refreshed seed category set: many categories added, removed, renamed, recolored and reassigned icons/classifications for clearer organization.
• Style
  • Internal formatting of icon lists cleaned up for readability (no change to visible icons).
• Tests
  • Bootstrap test expectation updated to reflect the new initial category count.

[coderabbitai]

Walkthrough

Reformatted icon_codes and substantially revised default_categories seed data in app/models/category.rb (many entries added, removed, renamed, recolored, or reclassified). Updated test expectation in test/controllers/categories_controller_test.rb to reflect bootstrap-created Category count change (12 → 19).

Changes

Cohort / File(s)	Summary
Category model data updates app/models/category.rb	Reformatted the icon_codes array; replaced the prior default_categories set with a substantially revised list (many new categories added, several removed or renamed, and multiple color/icon/classification values changed). No public API or method signatures modified.
Test expectation update test/controllers/categories_controller_test.rb	Adjusted bootstrap test assertion to expect 19 Category records created by bootstrap! instead of 12 to match the updated seed data.

Estimated code review effort

🎯 3 (Moderate) | ⏱️ ~20–30 minutes

Poem

🐰
I hopped through lists of color and code,
Rearranged nests along the road,
New names and icons found their place,
Seeds now sprout with brighter grace,
Bootstrap hums — I bound and bode.

Pre-merge checks and finishing touches

❌ Failed checks (1 warning, 1 inconclusive)

Check name	Status	Explanation	Resolution
Docstring Coverage	⚠️ Warning	Docstring coverage is 0.00% which is insufficient. The required threshold is 80.00%.	You can run @coderabbitai generate docstrings to improve docstring coverage.
Title Check	❓ Inconclusive	The title "Category improvements" is vague and generic, failing to convey specific information about the changeset. While it relates to the general subject matter (categories), it uses a non-descriptive term that could apply to any modification to the category model—whether bug fixes, refactoring, or feature additions. A teammate scanning the commit history would not understand that the primary changes involve expanding the default category set from 12 to 19 entries, updating category colors for better separation, and refreshing the icon set. The title lacks the specificity and clarity needed to communicate the main intent of the changes.	Consider revising the title to be more specific about the actual improvements made. For example, "Expand default categories and update icons and colors" or "Add new categories and improve category organization" would better communicate the main changes. This would help reviewers and future maintainers quickly understand the scope of modifications from the PR title alone.

✅ Passed checks (1 passed)

Check name	Status	Explanation
Description Check	✅ Passed	Check skipped - CodeRabbit’s high-level summary is enabled.

✨ 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.}

[coderabbitai]

Actionable comments posted: 1

📜 Review details

Configuration used: CodeRabbit UI

Review profile: CHILL

Plan: Pro

📥 Commits

Reviewing files that changed from the base of the PR and between 768e85c and ebb32bb.

📒 Files selected for processing (1)

• app/models/category.rb (2 hunks)

🧰 Additional context used

📓 Path-based instructions (9)

app/models/**/*.rb

📄 CodeRabbit inference engine (.cursor/rules/project-design.mdc)

Domain models should not call Provider::Registry directly; use a Provided concern within the model’s namespace to select providers and expose convenience methods

Use ActiveRecord validations for forms and complex domain constraints.

app/models/**/*.rb: Place business logic in POROs and model classes under app/models
Models should answer questions about themselves (e.g., prefer account.balance_series over service objects)
Implement complex validations and business logic with ActiveRecord validations
Model-level validations may mirror DB constraints but are not strictly required

Files:

• app/models/category.rb

app/**/*.rb

📄 CodeRabbit inference engine (AGENTS.md)

Place Rails application Ruby code (models, controllers, services, jobs, mailers, components) under app/

Files:

• app/models/category.rb

**/*.rb

📄 CodeRabbit inference engine (AGENTS.md)

Ruby style: 2-space indentation; snake_case for methods/variables; CamelCase for classes/modules

Files:

• app/models/category.rb

**/*.{rb,js,jsx,ts,tsx}

📄 CodeRabbit inference engine (.github/copilot-instructions.md)

**/*.{rb,js,jsx,ts,tsx}: Make changes atomic, testable, and explain their impact briefly in code suggestions.
Respect existing tests and add tests when changing critical logic.

Files:

• app/models/category.rb

**/app/**/*.{rb,erb,js,css}

📄 CodeRabbit inference engine (CLAUDE.md)

Push Rails to its limits before adding new dependencies; a strong technical/business reason is required for new dependencies.

Files:

• app/models/category.rb

**/app/models/**/*.rb

📄 CodeRabbit inference engine (CLAUDE.md)

Business logic should primarily reside in models; use concerns and POROs for organization.

Files:

• app/models/category.rb

**/*.{rb,erb,haml,slim}

📄 CodeRabbit inference engine (.cursor/rules/general-rules.mdc)

**/*.{rb,erb,haml,slim}: Use Current.user for the current user; do not use current_user
Use Current.family for the current family; do not use current_family
Ignore i18n methods; hardcode strings in English for now (do not use I18n.t, t, or similar)

Files:

• app/models/category.rb

app/{helpers,models}/**/*.rb

📄 CodeRabbit inference engine (.cursor/rules/project-conventions.mdc)

Format currencies, numbers, and dates on the server side (Ruby) before sending to the client

Files:

• app/models/category.rb

app/{models,controllers,views}/**/*.{rb,erb}

📄 CodeRabbit inference engine (.cursor/rules/project-conventions.mdc)

Avoid N+1 queries

Files:

• app/models/category.rb

🔇 Additional comments (3)

app/models/category.rb (3)

50-63: LGTM! Excellent formatting improvement.

The multi-line format significantly improves readability and maintainability of the icon list. The alphabetical organization makes it easy to find and verify icon names.

---

107-107: Verify the classification of "Savings & Investments" as an expense.

Classifying "Savings & Investments" as an "expense" is semantically unusual in accounting terms, as these are typically considered transfers or asset allocations rather than expenses. Please verify this aligns with the product requirements and user expectations for how savings and investment contributions should be categorized and reported.

---

66-74: Existing categories won't receive the new colors and icons.

The bootstrap! method uses find_or_create_by! which means existing categories with matching names won't be updated with the new colors, icons, or classifications. This could lead to visual inconsistencies for users who bootstrapped their database before this change. Consider whether a migration or update mechanism is needed to sync existing categories with the new defaults.

[coderabbitai]

Actionable comments posted: 1

📜 Review details

Configuration used: CodeRabbit UI

Review profile: CHILL

Plan: Pro

📥 Commits

Reviewing files that changed from the base of the PR and between ebb32bb and f12c2ea.

📒 Files selected for processing (1)

• test/controllers/categories_controller_test.rb (1 hunks)

🧰 Additional context used

📓 Path-based instructions (5)

test/**/*_test.rb

📄 CodeRabbit inference engine (AGENTS.md)

Name Minitest files with *_test.rb and mirror the app/ structure under test/

test/**/*_test.rb: ALWAYS use Minitest + fixtures + Mocha for tests; NEVER RSpec or FactoryBot.
Use Mocha for mocking in tests when necessary.
Use VCR for external API tests.

test/**/*_test.rb: Always use Minitest for tests; do not use RSpec
Do not use factories (e.g., FactoryBot) in tests; rely on fixtures instead
For tests needing many records, use Rails helpers to construct data and inline the creation in the test
Only write tests for critical and important code paths
Avoid tests that merely verify framework/ActiveRecord behavior
Test boundaries correctly: for queries, assert returned values; for commands, assert collaborators are called with correct params
Never test the implementation details of one class in another class’s test suite
Use the mocha gem for stubs and mocks
Prefer OpenStruct for mock instances; use a mock class for complex cases
Only mock what’s necessary; don’t mock return values unless they are under test

Files:

• test/controllers/categories_controller_test.rb

**/*.rb

📄 CodeRabbit inference engine (AGENTS.md)

Ruby style: 2-space indentation; snake_case for methods/variables; CamelCase for classes/modules

Files:

• test/controllers/categories_controller_test.rb

**/*.{rb,js,jsx,ts,tsx}

📄 CodeRabbit inference engine (.github/copilot-instructions.md)

**/*.{rb,js,jsx,ts,tsx}: Make changes atomic, testable, and explain their impact briefly in code suggestions.
Respect existing tests and add tests when changing critical logic.

Files:

• test/controllers/categories_controller_test.rb

**/test/**/*.rb

📄 CodeRabbit inference engine (CLAUDE.md)

**/test/**/*.rb: ALWAYS use Minitest and fixtures for Ruby tests; NEVER RSpec or factories.
Only test critical and important code paths; system tests should be used sparingly for critical user flows.

Files:

• test/controllers/categories_controller_test.rb

**/*.{rb,erb,haml,slim}

📄 CodeRabbit inference engine (.cursor/rules/general-rules.mdc)

**/*.{rb,erb,haml,slim}: Use Current.user for the current user; do not use current_user
Use Current.family for the current family; do not use current_family
Ignore i18n methods; hardcode strings in English for now (do not use I18n.t, t, or similar)

Files:

• test/controllers/categories_controller_test.rb

⏰ Context from checks skipped due to timeout of 90000ms. You can increase the timeout in your CodeRabbit configuration to a maximum of 15 minutes (900000ms). (1)

• GitHub Check: ci / test

[coderabbitai]

Actionable comments posted: 0

🧹 Nitpick comments (2)

app/models/category.rb (2)

50-63: Icon list looks solid; sample names verified against Lucide.

Spot-checked icons exist: ice-cream-cone, trees, bed-single, hand-helping, drama, landmark. Looks good.

• Optional: move this to a frozen constant (ICON_CODES) and sort alphabetically for diffability.

References: ice-cream-cone, trees, bed-single, hand-helping, drama, landmark. (lucide.dev)

---

87-107: Good improvement: unique, clearer category palette; confirm classification and add guardrail.

• Colors now appear unique across defaults; aligns with the PR goal of better separation.
• Confirm “Savings & Investments” being classified as "expense" is intentional for reporting.
• Recommend adding a simple inclusion validation to prevent typos in future seed edits.

Example:

# keep optional if `uncategorized` stays unsaved
validates :classification, inclusion: { in: %w[income expense] }, allow_nil: true

📜 Review details

Configuration used: CodeRabbit UI

Review profile: CHILL

Plan: Pro

📥 Commits

Reviewing files that changed from the base of the PR and between f12c2ea and cef3005.

📒 Files selected for processing (1)

• app/models/category.rb (2 hunks)

🧰 Additional context used

📓 Path-based instructions (9)

app/models/**/*.rb

📄 CodeRabbit inference engine (.cursor/rules/project-design.mdc)

Domain models should not call Provider::Registry directly; use a Provided concern within the model’s namespace to select providers and expose convenience methods

Use ActiveRecord validations for forms and complex domain constraints.

app/models/**/*.rb: Place business logic in POROs and model classes under app/models
Models should answer questions about themselves (e.g., prefer account.balance_series over service objects)
Implement complex validations and business logic with ActiveRecord validations
Model-level validations may mirror DB constraints but are not strictly required

Files:

• app/models/category.rb

app/**/*.rb

📄 CodeRabbit inference engine (AGENTS.md)

Place Rails application Ruby code (models, controllers, services, jobs, mailers, components) under app/

Files:

• app/models/category.rb

**/*.rb

📄 CodeRabbit inference engine (AGENTS.md)

Ruby style: 2-space indentation; snake_case for methods/variables; CamelCase for classes/modules

Files:

• app/models/category.rb

**/*.{rb,js,jsx,ts,tsx}

📄 CodeRabbit inference engine (.github/copilot-instructions.md)

**/*.{rb,js,jsx,ts,tsx}: Make changes atomic, testable, and explain their impact briefly in code suggestions.
Respect existing tests and add tests when changing critical logic.

Files:

• app/models/category.rb

**/app/**/*.{rb,erb,js,css}

📄 CodeRabbit inference engine (CLAUDE.md)

Push Rails to its limits before adding new dependencies; a strong technical/business reason is required for new dependencies.

Files:

• app/models/category.rb

**/app/models/**/*.rb

📄 CodeRabbit inference engine (CLAUDE.md)

Business logic should primarily reside in models; use concerns and POROs for organization.

Files:

• app/models/category.rb

**/*.{rb,erb,haml,slim}

📄 CodeRabbit inference engine (.cursor/rules/general-rules.mdc)

**/*.{rb,erb,haml,slim}: Use Current.user for the current user; do not use current_user
Use Current.family for the current family; do not use current_family
Ignore i18n methods; hardcode strings in English for now (do not use I18n.t, t, or similar)

Files:

• app/models/category.rb

app/{helpers,models}/**/*.rb

📄 CodeRabbit inference engine (.cursor/rules/project-conventions.mdc)

Format currencies, numbers, and dates on the server side (Ruby) before sending to the client

Files:

• app/models/category.rb

app/{models,controllers,views}/**/*.{rb,erb}

📄 CodeRabbit inference engine (.cursor/rules/project-conventions.mdc)

Avoid N+1 queries

Files:

• app/models/category.rb

⏰ Context from checks skipped due to timeout of 90000ms. You can increase the timeout in your CodeRabbit configuration to a maximum of 15 minutes (900000ms). (1)

• GitHub Check: ci / test

🔇 Additional comments (1)

app/models/category.rb (1)

66-74: Scoping concern is valid but implementation is currently functional via association scope—consider as defensive refactor rather than blocker.

Current.family.categories.bootstrap! calls the method on an association scope, which provides implicit family filtering. However, the method doesn't make family scoping explicit in its signature, relying instead on Rails association proxy behavior. While the test passes, this design is fragile.

The suggested fix improves clarity and prevents misuse:

-    def bootstrap!
-      default_categories.each do |name, color, icon, classification|
-        find_or_create_by!(name: name) do |category|
+    def bootstrap!(family: Current.family)
+      default_categories.each do |name, color, icon, classification|
+        find_or_create_by!(family: family, name: name) do |category|
           category.color = color
           category.classification = classification
           category.lucide_icon = icon
         end
       end
     end

Also update the controller call from Current.family.categories.bootstrap! to Current.family.categories.bootstrap!(family: Current.family) (or just bootstrap! since the default matches).

[jjmata]

Definitely a quick win that adds to the variety of icons available as discussed in #218 ... so merging it today given the simplicity.

Since we're discussing OCD as it relates to categories ... my 2 cents' for @sokie and others who might want to react. :-)

Finding the right balance of categories to get started is hard: too many and you scare the user away, too few and people think "not powerful enough for me!" and then there is the whole OCD around colors/organization.

After many years of Quicken usage, I do like my subcategories (cut orthogonally by tags ... a discussion for another day!) and the code has a little known rake demo_data:sample task that creates what I find to be a very beautiful set of categories like so:

[jjmata]

What I like in that list is the grouping by color, and also simplicity in the number of them. We could argue for ages about what the right list is (and maybe how it should be dependent on a question we ask during onboarding, right?) but like I said this is great already as is so taking it in right away! 🚀 Should probably move this rant to #218 anyway. ;-)

[sokie]

Definitely a quick win that adds to the variety of icons available as discussed in #218 ... so merging it today given the simplicity.

Since we're discussing OCD as it relates to categories ... my 2 cents' for @sokie and others who might want to react. :-)

Finding the right balance of categories to get started is hard: too many and you scare the user away, too few and people think "not powerful enough for me!" and then there is the whole OCD around colors/organization.

After many years of Quicken usage, I do like my subcategories (cut orthogonally by tags ... a discussion for another day!) and the code has a little known rake demo_data:sample task that creates what I find to be a very beautiful set of categories like so:

Damn I didn't know about that command. I do really like the sub categories.
@jjmata I would love to have sure react more to user input where registering, so you can have kinda like a scale from power user down to super simple. And then expand categories also to have sub categories and stuff.
In the future also show more sections or maybe unlock some "advanced " features.
I think it would be amazing