[$175] Search functionality is not available in payment history or payment details page #104963

Activity

1. applause-bot

   added

   DailyKSv2KSv2

   BugSomething is broken. Auto assigns a BugZero manager.Something is broken. Auto assigns a BugZero manager.

   on Oct 26, 2026
2. applause-bot commented on Oct 26, 2026

   

   applause-botBot

   on Oct 26, 2026

   Author

   More actions

   While Applause doesn't embed attachments for this bug, here are the links for quick view:
   https://platform.applause.com/services/links/v1/external/6b6a7901c9d139240da8c03fe2cbe1247e4e169e63952542c658f4c446c7a9c3
3. gleitebr

   added this to #expensify-bugson Oct 26, 2026
4. MelvinBot commented on Oct 26, 2026

   

   MelvinBot

   on Oct 26, 2026

   Contributor

   More actions

   Proposal

   What is the root cause of that problem?

   This is expected behavior, not a bug. The QA steps are missing a precondition.

   • Payment details page: The "Find an active user" search field only shows when the month has 12 or more active users (CONST.STANDARD_LIST_ITEM_LIMIT). See PaymentActivityTable/index.tsx:68. The tester's account likely has fewer than 12 active users, so the search field stays hidden.
   • Payment history page: This page never had a search field. [CFI] Payment history: Activity list with the active user count only added search to the Payment details page.

   Design confirmed the 12-user rule during review, in this comment on the PR. The PR's QA step "Verify the search functionality works well" didn't mention that a month needs 12+ active users.

   What changes do you think we should make in order to solve the problem?

   No code change is needed under the current rule. To retest, QA should open a month with 12 or more active users. Then confirm that:

   1. The search field appears.
   2. Searching filters by name or email.
   3. A search with no matches shows "No results found".

   If design decides to always show the search field, as shawnborton mentioned tables usually do, remove the 12-user check at PaymentActivityTable/index.tsx:68. Then always pass Table.FilterBar when the month has active users, and update the hidden-search case in tests/ui/PaymentDetailsPageTest.tsx.

   What alternative solutions did you explore? (Optional)

   Adding search to the Payment history list page. That page wasn't in scope for [$175] [CFI][FE 5/7] Payment history: Activity list with the active user count, so it would need its own design decision.

   Related issues

   • [$175] Active users count are different on payment history and payment details page was filed from the same QA run. It's a separate issue.

   ---

   Next Steps for Contributor+ team:
   To accept: @MelvinBot implement [this](https://github.com/Expensify/App/issues/104963) to create a draft PR.
   To refine: @MelvinBot <your feedback>
   To reject: Explain why you are rejecting Melvin's proposal.

   ---

   view run
5. MelvinBot

   added

   ExternalAdded to denote the issue can be worked on by a contributorAdded to denote the issue can be worked on by a contributor

   on Oct 26, 2026
6. melvin-bot

   assigned

   nyomanjyotisa

   on Oct 26, 2026
7. melvin-bot commented on Oct 26, 2026

   

   melvin-botBot

   on Oct 26, 2026 – with Melvin Bot

   More actions

   Triggered auto assignment to Contributor-plus team member for initial proposal review - @nyomanjyotisa (External)
8. melvin-bot

   changed the title [-]Search functionality is not available in payment history or payment details page[/-] [+][$175] Search functionality is not available in payment history or payment details page[/+] on Oct 26, 2026
9. melvin-bot commented on Oct 26, 2026

   

   melvin-botBot

   on Oct 26, 2026 – with Melvin Bot

   More actions

   Job added to Upwork: https://www.upwork.com/jobs/~022114590709932768249
10. camesenin commented on Oct 26, 2026

    

    camesenin

    on Oct 26, 2026

    More actions

    Proposal

    Please re-state the problem that we are trying to solve in this issue.

    QA reported missing search controls on the payment history and payment details pages. The supplied evidence does not establish whether search is missing contrary to the approved design or intentionally hidden because the selected month has too few active users.

    What is the root cause of that problem?

    The reported defect is not yet demonstrated. The supplied tests/ui/PaymentDetailsPageTest.tsx explicitly asserts that search is hidden for two distinct active users and constructs a larger fixture using CONST.STANDARD_LIST_ITEM_LIMIT.

    MelvinBot attributes that behavior to src/components/Tables/PaymentActivityTable/index.tsx:68. However, the implementation and linked design comment could not be retrieved, and this workspace contains no Expensify checkout. That location and the claimed design approval remain independently unverified.

    The evidence supports an intentional threshold in the supplied test, but does not establish:

    • The affected purchase’s distinct active-user count.
    • Whether the rendered implementation uses the original or filtered list to determine search visibility.
    • Whether payment history search was an approved requirement.

    No security impact or CVSS classification is supported.

    What changes do you think we should make in order to solve the problem?

    No production TypeScript change is justified by the available evidence. Removing the threshold would change the behavior explicitly asserted by the supplied test.

    First, reproduce with a loaded purchase containing exactly CONST.STANDARD_LIST_ITEM_LIMIT distinct active users. Record the purchase fixture, rendered search control, and filtering results.

    The resulting disposition should follow the evidence:

    • If search appears and filters correctly, correct the QA precondition.
    • If search is absent at the threshold, investigate the component’s actual visibility condition.
    • If filtering causes the control to disappear, base visibility on the unfiltered distinct-user collection, preserving the existing threshold.
    • If design requires search for smaller lists, update the visibility condition and its existing test together.

    An exact production diff would require the component source. Inventing its variable names, condition, or verified line numbers would make this proposal unreliable.

    What alternative solutions did you explore? (Optional)

    MelvinBot’s conclusion is plausible but premature. “The tester likely has fewer than 12 active users” is a hypothesis without the affected purchase data. Its proposed retest also omits threshold boundaries and whether the search input survives filtering below the threshold.

    Conversely, there is no evidence that MelvinBot’s implementation contains those failures. They are cases to verify, not established defects.

    Removing the threshold duplicates MelvinBot’s own alternative and contradicts the supplied hidden-search assertion. Adding payment history search introduces a separate feature without verified requirements.

    Expensify also requires meaningful differences between competing proposals; these additional checks alone do not establish an original bounty solution. See the contribution requirements.

    What automated tests can you add to prevent this from re-occurring?

    Add this boundary test inside the supplied PaymentDetailsPage Activity list suite:

    it.each([
        [CONST.STANDARD_LIST_ITEM_LIMIT - 1, false],
        [CONST.STANDARD_LIST_ITEM_LIMIT, true],
    ] as const)(
        'sets search visibility correctly for %i distinct active users',
        async (count, shouldShowSearch) => {
            const members = [BOB, TODD, ...OTHER_MEMBERS].slice(0, count);
            await setPurchase(members.map(({accountID}) => accountID));
    
            renderPage();
            await screen.findByText(BOB.displayName);
    
            await waitFor(() => {
                const input = screen.queryByPlaceholderText(SEARCH_PLACEHOLDER);
                if (shouldShowSearch) {
                    expect(input).toBeOnTheScreen();
                } else {
                    expect(input).toBeNull();
                }
            });
        },
    );

    Extend the existing filtering test to assert that:

    1. Searching Bob’s display name leaves Bob visible and removes Todd.
    2. Searching Bob’s email produces the same result.
    3. An unmatched query shows the existing empty-results state while keeping search available.
    4. Clearing the query restores both members.
    5. Repeating one account ID does not push a below-threshold distinct-user count over the threshold.

    These are proposed assertions, not executed results. The supplied file is truncated, and the application and Jest environment are unavailable here.

    Contributor details
    Your Expensify account email: camesenin@gmail.com
    Upwork Profile Link: https://www.upwork.com/freelancers/~01b60d704ba377be83
11. melvin-bot commented on Oct 26, 2026

    

    melvin-botBot

    on Oct 26, 2026 – with Melvin Bot

    More actions

    ✅ Contributor details stored successfully. Thank you for contributing to Expensify!
12. shilo1979jk commented on Oct 26, 2026

    

    shilo1979jk

    on Oct 26, 2026

    More actions

    Proposal

    Please re-state the problem that we are trying to solve in this issue.

    On Settings > Subscription > View payment history and Payment details, no search bar is visible to filter active users when the payment entry has fewer than 12 active users.

    What is the root cause of that problem?

    In src/components/Tables/PaymentActivityTable/index.tsx:68, <Table.FilterBar /> is gated behind activeUsers.length >= CONST.STANDARD_LIST_ITEM_LIMIT (12):

    {activeUsers.length >= CONST.STANDARD_LIST_ITEM_LIMIT && (
        <View style={[styles.ph5, styles.pb5]}>
            <Table.FilterBar />
        </View>
    )}

    However, the QA test steps and product expectation in PR #104325 ("Verify search functionality works to find users") expect the search input on the Payment Details activity table to be available whenever active users are listed (activeUsers.length > 0), or the threshold prevents searching on standard workspaces with fewer than 12 active users.

    What changes do you think we should make in order to solve the problem?

    In src/components/Tables/PaymentActivityTable/index.tsx:68, render <Table.FilterBar /> whenever activeUsers.length > 0 (or lower the threshold) so users can search the payment activity table regardless of whether the workspace has 12+ billed users.
13. nyomanjyotisa commented on Oct 26, 2026

    

    nyomanjyotisa

    on Oct 26, 2026

    Member

    More actions

    @jponikarchuk Search on Payment details is intentionally shown only for 12+ active users (confirmed here). Payment history has no search. Could you retest a month with 12+ active users?

    👍React with 👍1Reacted by Julia Ponikarchuk
14. trjExpensify commented on Oct 26, 2026

    

    trjExpensify

    on Oct 26, 2026

    Contributor

    More actions

    Closing, expected.
15. trjExpensify

    closed this as completedon Oct 26, 2026
16. github-project-automation

    moved this to Done in #expensify-bugson Oct 26, 2026