feat: deploy seen-once logic for goal in review modal in my kiva and … by christian14b · Pull Request #7148 · kiva/ui

christian14b · 2026-08-07T16:36:43Z

…portfolio pages

Opens the Goal in Review modal, once per user in total across both My Kiva and Portfolio pages.

What changed

A seen-once flag the feature owns. goalRecapViewed[year] is written to user preferences when the recap opens, so opening and dismissing both count as seen. It is server side, so it holds across pages, sessions and devices (a cookie would not).
A pending marker for the "session after completion" rule. goalRecapPending[year] is set the first time a completed goal is seen, and the recap opens on the visit after that.
** Both pages ask the same question.** Every rule about when the recap should appear lives in one place, shouldAutoOpenRecap. It takes the things it needs as arguments and answers yes or no, so each rule can be tested on its own without standing up a page.
Portfolio now renders the modal. It computed goalInReviewEnable but never had GoalInReviewModal mounted.

Trigger rules

Goal state	Behaviour
Completed, first sighting	nothing shown, arms `goalRecapPending[year]`
Completed, already pending	opens, marks `goalRecapViewed[year]`
In progress	opens on the first visit once the flag is on
Already seen	never again, on either page
Previous year or expired	never
No goal, or no loans toward it	never
Feature flag off	never

On MyKiva a ?goTo=goal-recap deep link returns early and skips the auto-open, so an explicit link does not silently consume the once-only flag. The deep link also does not set the flag, so a link in an email keeps working however many times it is clicked.

Test instructions - VQA

You need:

goal_in_review_enable switched on.
A logged in lender with a goal for the current year and at least one loan toward it.

Use /mykiva or /portfolio with no query parameters. A ?goTo=goal-recap parameter skips the auto-open path deliberately.

Check your starting state

Run this in the gateway while logged in as the test account:

query { my { id userPreferences { id preferences } } }

Look inside the preferences JSON for goalRecapViewed and goalRecapPending. They determine what happens next, and they are stored on the account (clearing cookies or changing browser will not reset them).

Scenarios

In progress goal

No flags set. Visit /mykiva -> the recap opens.
Reload -> nothing. goalRecapViewed[year] is now set.
Visit /portfolio -> nothing. This is the "once in total, not once per page".

Completed goal

No flags set. Visit /mykiva -> nothing shown. This is the session they completed in. goalRecapPending[year] is now set.
Visit /mykiva or /portfolio again -> the recap opens.
Anywhere after that -> nothing.

Portfolio page, without visiting MyKiva

Worth running as its own pass. The completed-goal rule is driven by goalRecapPending[year], which either page can set, so a lender who only ever visits Portfolio gets the same two-step behaviour as one who uses MyKiva:

Completed goal, no flags. Visit /portfolio → nothing, arms the marker.
Visit /portfolio again -> opens.
Visit /mykiva -> nothing.

Dismissal counts as seen

Open the recap, then close it with the X or by clicking outside it. Reload -> it does not come back. The flag is written when it opens, not when it is read.

Cases that must never pop

A goal from a previous year, or an expired goal.
A lender with no goal, or a goal with no loans toward it.
Anyone, with goal_in_review_enable off.

Resetting between runs

The flags are written to the account, so each scenario is one-shot. To run them again, clear goalRecapViewed and goalRecapPending from that user's preferences.

…portfolio pages

roger-in-kiva · 2026-08-07T16:39:32Z

 		GoalEntrypoint
 	},
+	setup() {
+		const apollo = inject('apollo');


Is there a way to avoid injecting apollo twice?

Interesting question, I'll take a look

Also, useGoalInReview({ apollo }) spins up a useGoalData internally, and setup creates a second one directly. Since userPreferences is a per-call ref(null) rather than module-scoped, the instance loadAutoOpenRecap writes goalRecapViewed/goalRecapPending into is a different reactive store from the one the page reads feedback state from. It works today only because everything reloads network-only, but it's a duplicate round-trip and a divergence trap if anything later leans on shared reactive prefs. Could we thread one useGoalData through, or have useGoalInReview re-expose the feedback helpers the page needs? (MyKiva has the same shape.)

Good catch! and it was worse than two. MyKiva had three useGoalData instances: the page-wide one MyKivaPage provides, the one MyKivaPageContent was injecting, and the one useGoalInReview creates internally. Portfolio had two.

Indeed, userPreferences is ref(null) inside the composable, so each call gets its own store, and it only worked because every read forced network-only.

I will fix it by letting useGoalInReview accept an existing instance

dyersituations · 2026-08-07T18:38:27Z

+		if (!year) return;
+		const parsedPrefs = await loadPreferences('network-only');
+		const prev = parsedPrefs?.goalRecapViewed || {};
+		// Year-keyed flag so seeing this year's recap does not suppress next year's.


I don't know if this comment is accurate.

dyersituations · 2026-08-07T18:38:58Z

+
+	const goalRecapPendingByYear = computed(() => {
+		const parsedPrefs = JSON.parse(userPreferences.value?.preferences || '{}');
+		return parsedPrefs.goalRecapPending || {};


There are two methods here that are really similar and could be combined and passed a key.

dyersituations · 2026-08-07T18:39:12Z

+	});
+
+	function hasGoalRecapPendingForYear(year) {
+		return Boolean(goalRecapPendingByYear.value?.[year]);


Similarly this method could be combined/abstracted.

dyersituations · 2026-08-07T18:39:51Z

+
+	// Set the first time a completed goal is seen, so the recap can open on the session
+	// after completion without depending on the goal card's own celebration flag.
+	async function setGoalRecapPendingPreference(year = GOALS_CURRENT_YEAR) {


Another method that is almost duplicated above.

dyersituations · 2026-08-07T18:42:24Z

+	// In progress goal setters are reached when the feature itself goes live, so the
+	// flag is the only gate.
+	if (goalStatus === GOAL_STATUS.IN_PROGRESS) {
+		return true;


This means any in-progress goal is shown in the new modal after the feature is enabled?

Yes, called out in the epic:

Lenders who still have a goal in progress - show on log in as a pop up when they visit MyKiva or the Portfolio mid November just pop up once (total, not once per page)

That mentions "mid November" instead of when the feature is enabled. Is that "November" check already in place for in-progress goals?

dyersituations · 2026-08-07T18:44:16Z

+				return;
+			}
+			await this.loadGoalPreferences('network-only');
+			this.goalInReviewFeedbackSubmitted = this.hasSubmittedGoalFeedbackForYear(goalInReview.year);


Why is goalInReviewFeedbackSubmitted set here?

dyersituations · 2026-08-07T18:45:16Z

+			hasCompletionPending,
+		});
+
+		if (!shouldOpen) {


Why are we exiting if the user just completed a goal? Wouldn't this be true when returning to MyKiva after checking out the last loan? And I assume we'd want to show the new modal then?

It's called out in the epic too: Lenders who completed their goal - the next session after they complete their goal, show as a pop up when they visit MyKiva or the Portfolio , but I'll reconfirm it asking in the channel

Ah, so first load on MyKiva sets the pending, second load shows?

… logic

Christian Bedon added 3 commits August 7, 2026 10:07

feat: deploy seen-once logic for goal in review modal in my kiva and …

62ded92

…portfolio pages

fix: wrong comment mentioning cdn

3034a1b

fix: form padding bottom

e590f24

christian14b requested a review from a team August 7, 2026 16:36

christian14b added the b2c Sends B2C team a message in Slack on PR creation label Aug 7, 2026

roger-in-kiva reviewed Aug 7, 2026

View reviewed changes

dyersituations reviewed Aug 7, 2026

View reviewed changes

Christian Bedon added 3 commits August 7, 2026 14:22

fix: avoid multiple instances of useGoalData

0597e0b

fix: refactor useGoalData new methods to avoid duplication or similar…

de3747d

… logic

feat: add start date to trigger goal in review for in-progress goals

b3cccbc

Uh oh!

Conversation

christian14b commented Aug 7, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

What changed

Trigger rules

Test instructions - VQA

Check your starting state

Scenarios

Resetting between runs

Uh oh!

Choose a reason for hiding this comment

Uh oh!

christian14b Aug 7, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

3 participants

christian14b commented Aug 7, 2026 •

edited

Loading

christian14b Aug 7, 2026 •

edited

Loading