mirror of
https://github.com/we-promise/sure.git
synced 2026-09-06 15:14:19 +00:00
buzzromainandClaude Opus 5
ff48acd04b
* feat(goals): offer recording a spend where the user is standing Adding money had a button on the goal page. Using it had none — the entry lived in the overflow menu, behind three conditions, and nowhere else. The asymmetry bit hardest at the one moment it mattered. "Record pledge" disappears once a goal is reached, so a user who hit the target and then spent some of it arrived at a page offering a single action: "Close this goal". That releases the earmark, and its own hint tells them to do it "once you have actually spent it" — asking for something the page gave them no way to say. The celebration panel now offers it beside closing, in that order, because that is the order the two happen in and closing is the one another click cannot undo. Same condition as the menu entry, which stays where it is: this is a second door, not a move. Beside, never instead. Plenty of goals are closed with nothing recorded, and the offer must not read as a step to clear first — a test pins that closing is still offered whenever it was before. The row is conditional rather than always rendered: a reserve gets neither action, and an empty flex div still carries its top margin, which would open a gap under copy that says there is nothing to do. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_016GTNba5qE5NwzaHzbp27ye * fix(goals): hold the spend offer to accounts the reader can reach Review on #3215. `offer_recording_a_spend?` rode on `current_balance`, which counts every linked account — private ones included. A reader backed only by somebody else's private account was shown the link, then sent to a dialog with nothing to pick and a refusal on submit. The dialog has applied this scoping since #3176; the panel that points at it had not. It goes through `backing_within` now, on the reader's own accessible accounts. The component tests gained a session for the same reason: without a reader the offer is correctly withheld, so every assertion about it was measuring the wrong thing. Also from review: the reserve's empty-row test renders the component rather than only asking its predicates. Both could stay false while the template emitted the row anyway, which is precisely the gap that test exists for — it needed `ViewComponent::TestCase` to do it. The two page tests move above the first `private`. They did run where they were — Rails' `test` macro defines methods through `define_method` from a class method, which is public regardless of the surrounding visibility, and `-n` confirms Minitest picks them up — but tests wedged between private helpers read as a mistake whether or not they behave like one. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_016GTNba5qE5NwzaHzbp27ye * fix(goals): close the second door to the spend dialog Review on #3215. Scoping the offer to the reader's own accounts fixed the lifecycle panel and left the overflow menu on the old condition, so the two doors to the same dialog disagreed — and the older one still had the bug the newer one was written to avoid. A reader backed only by another member's private account was shown the menu entry, opened a dialog with nothing to pick, and was refused on submit. The question moves to the goal, where both doors ask it, and the reader's accounts come from the list the controller already builds for the dialog. That also removes the component's own broader lookup: it was plucking every accessible account on each goal-show render, duplicating work done upstream in the same request. It now takes the ids in, defaulting to none — a caller that forgets them withholds the offer, which is the safe way to be wrong about a permission. A controller test pins it page-wide, since the point is that neither door may offer it; putting the old condition back makes it fail. Also from review: the panel test claimed to be scoped to the panel while selecting `section`, which DS::Card emits for every card on the page. The action row has an id now and both tests use it. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_016GTNba5qE5NwzaHzbp27ye --------- Co-authored-by: Claude Opus 5 <noreply@anthropic.com>
109 lines
4.4 KiB
Ruby
109 lines
4.4 KiB
Ruby
# The panel between the goal header and its funding breakdown. Which panel a
|
|
# goal gets is a lifecycle question with five answers, and the template used to
|
|
# work it out inline from `completed?`, `maintained?`, `one_off?`, `status` and
|
|
# `may_complete?` — five predicates deep in ERB, where the ordering between
|
|
# them mattered and nothing said so.
|
|
#
|
|
# The decision lives here; the template only renders the answer.
|
|
class Goals::LifecyclePanelComponent < ApplicationComponent
|
|
attr_reader :goal
|
|
|
|
# `viewer_account_ids` are the goal's accounts THIS READER can reach, worked
|
|
# out once in the controller and shared with the overflow menu. Defaulting to
|
|
# none rather than to every account: a caller that forgets them withholds the
|
|
# spend offer, which is the safe way to be wrong about a permission.
|
|
def initialize(goal:, viewer_account_ids: [])
|
|
@goal = goal
|
|
@viewer_account_ids = viewer_account_ids
|
|
end
|
|
|
|
# Order is load-bearing, so it is stated once, here.
|
|
#
|
|
# `:reserve_shortfall` comes before `:empty`: a brand-new reserve sits at
|
|
# zero balance and zero pace, and the generic "make your first transfer"
|
|
# card would swallow it — where what it needs is the one figure a projection
|
|
# cannot show, how far it is below its floor. Ordering it after also meant
|
|
# asking a reserve for a pace it does not have.
|
|
def panel
|
|
return :inactive if goal.archived? || goal.paused?
|
|
return :celebration if goal.completed? || goal.status == :reached || goal.status == :funded
|
|
return :reserve_shortfall if goal.maintained?
|
|
return :empty if goal.current_balance.to_d.zero? && goal.pace.to_d.zero?
|
|
|
|
:projection
|
|
end
|
|
|
|
# --- inactive ---
|
|
|
|
def inactive_icon = goal.archived? ? "archive" : "pause"
|
|
|
|
def inactive_heading_key
|
|
goal.archived? ? "inactive.heading_archived" : "inactive.heading_paused"
|
|
end
|
|
|
|
# --- celebration ---
|
|
|
|
# Two situations reach this panel and they are not the same thing. A
|
|
# `completed` goal is closed: its earmark has been released and its amount
|
|
# frozen. A goal merely at 100% is still holding its money and still
|
|
# competing with its siblings on the account.
|
|
def closed? = goal.completed?
|
|
|
|
def celebration_icon = goal.maintained? ? "shield-check" : "party-popper"
|
|
|
|
def celebration_heading_key
|
|
goal.maintained? ? "celebration.heading_reserve" : "celebration.heading"
|
|
end
|
|
|
|
def celebration_body_key
|
|
return "celebration.body_reserve" if goal.maintained?
|
|
|
|
closed? ? "celebration.body" : "celebration.body_reached"
|
|
end
|
|
|
|
def show_frozen_note? = closed? && goal.completed_at.present?
|
|
|
|
# A reserve at its floor is in its normal state, not waiting to be closed:
|
|
# offering to release the money would be offering to undo the thing it
|
|
# exists for. Closing is also what releases the earmark, where archiving is
|
|
# the gesture that does not — so a goal merely at 100% is offered `:close`,
|
|
# not `:archive`.
|
|
def celebration_action
|
|
return :none if goal.maintained?
|
|
return :close if !closed? && goal.one_off? && goal.may_complete?
|
|
return :archive if goal.may_archive?
|
|
|
|
:none
|
|
end
|
|
|
|
# Using the money is the step that normally comes *before* closing — the
|
|
# close hint says so itself, "Do this once you have actually spent it" — and
|
|
# until now the only way to say so was an entry in the overflow menu, at the
|
|
# exact moment the page stops offering any other action. Adding money had a
|
|
# button on this page; using it had none.
|
|
#
|
|
# Offered beside closing, never instead of it: plenty of goals are closed
|
|
# without anything being recorded, and this must not read as a step to clear
|
|
# first. Same condition as the menu entry, which stays where it is.
|
|
def offer_recording_a_spend? = goal.spendable_within?(@viewer_account_ids)
|
|
|
|
# --- projection ---
|
|
|
|
|
|
# The chart draws its projection line with these same two variables
|
|
# (`goal_projection_chart_controller.js`), so the legend swatch has to use
|
|
# them too rather than the semantic border tokens — a legend whose colour
|
|
# does not match its line is worse than the markup it would save.
|
|
def projection_color
|
|
goal.status == :on_track ? "var(--color-green-600)" : "var(--color-yellow-600)"
|
|
end
|
|
|
|
def show_catch_up? = goal.status == :behind && goal.monthly_target_amount.present?
|
|
|
|
def show_projection_legend? = goal.target_date.present?
|
|
|
|
def show_required_legend?
|
|
goal.monthly_target_amount.to_d.positive? && goal.remaining_amount.to_d.positive?
|
|
end
|
|
end
|