* fix(transactions): don't crash the rule-prompt flash when clearing a category
needs_rule_notification? only checked saved_change_to_category_id? and
eligible_for_category_rule?, neither of which accounts for category_id
being nil. Clearing a category (Clear category / entryable_attributes
category_id: nil) satisfies both, so the caller went on to read
transaction.category.name against a nil category and crashed.
A rule prompt only makes sense when a category was assigned, not
cleared, so bail out early when there's no category to build a rule
around.
* feat(transactions): surface recently-used categories in the category picker
Reframes the recency-vs-muscle-memory question as additive, not
either/or: a small "Recent" section pinned above the existing
alphabetical list, which stays exactly where it always was below it.
Precedent for reordering the primary list by frequency (Office's old
adaptive menus, browser-history-style resorting) is a well-known
anti-pattern — position drifts under the user's hand. Every picker
that does recency well (VS Code's command palette, Spotify, Slack's
emoji picker) adds a small separate recent cluster instead.
- Category#last_used_at, touched only in
TransactionCategoriesController#update — the one place a category is
actually hand-picked by a person, as opposed to a rule or import
auto-assigning one.
- Category.recently_used_for(family:, excluding:, limit:) batches the
family-scoped query; dropdowns_controller excludes the already-
selected category from the Recent section since it's already pinned
to the top of the main list.
- "Recent" hides itself the moment a search query is typed — it's a
pre-search shortcut, not a second copy of search results. Its rows
are force-hidden (not just filtered) so keyboard nav can't land on a
row that's invisible only because its ancestor section is hidden.
* fix(categories): address review feedback on recent-categories picker
- Track last_used_at from every manual assignment path (transaction edit
form, categorization wizard bulk-update, create-and-assign), not just
the category-picker endpoint. Centralized as Transaction#record_category_usage!,
called explicitly from each manual controller action rather than wired
to a blanket after_save callback, since rule/import auto-assignment
must not count as a "recent" pick.
- Give recent-section rows a distinct DOM id (recent_category_option_<id>)
from their canonical-list counterpart so aria-activedescendant can't
resolve to a hidden duplicate during keyboard nav.
- Fix migration to ActiveRecord::Migration[7.2] to match the rest of the repo.
- Materialize @recent_categories with .to_a to avoid a redundant query.
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
* Move Transfer to Account namespace
* Fix partial resolution due to namespacing plurality
* Make category and tag controllers consistent with namespacing convention
* Update stale partial reference
Guillem Arias Fauste