[MelvinBot]

Explanation of Change

Help site follow-up for #98326, which added a paid-by: search filter. It was undocumented, so members had no way to discover the operator from the help site.

One article changes:

• docs/articles/new-expensify/reports-and-expenses/Use-Search-Operators-to-Filter-and-Analyze.md — adds a paid-by: row to the report operator table, including that values can be combined with commas, that unpaid reports never match, and that the operator also works on expense, invoice, and trip searches. Placed directly after paid-status: so the payment-related operators stay together. Keywords were extended so searches for "paid by" reach the article.

This PR originally also documented the Paid by column in Using-Reports-in-New-Expensify.md. That change was dropped when main was merged, because #100057 already documents the Paid by column and filter in that article.

Labels were verified against the live app on web: paid-by: is accepted in the search bar and the Filters row is labeled exactly Paid by.

No new article was created — the change extends an existing table, so the one-workflow-per-article rule in docs/HELP_AUTHORING_GUIDELINES.md is unaffected. No headings were added or changed, and no screenshots are needed.

Fixed Issues

$ #98326
PROPOSAL:

Tests

// TODO: The human co-author must fill out the tests you ran before marking this PR as "ready for review"
// Please describe what tests you performed that validates your changed worked.

• Verify that no errors appear in the JS console

Offline tests

N/A — documentation only.

QA Steps

// TODO: The human co-author must fill out the QA tests you ran before marking this PR as "ready for review".
// Please describe what QA needs to do to validate your changes and what areas do they need to test for regressions.

• Verify that no errors appear in the JS console

PR Author Checklist

• I linked the correct issue in the ### Fixed Issues section above
• I wrote clear testing steps that cover the changes made in this PR
  • I added steps for local testing in the Tests section
  • I added steps for the expected offline behavior in the Offline steps section
  • I added steps for Staging and/or Production testing in the QA steps section
  • I added steps to cover failure scenarios (i.e. verify an input displays the correct error message if the entered data is not correct)
  • I turned off my network connection and tested it while offline to ensure it matches the expected behavior (i.e. verify the default avatar icon is displayed if app is offline)
  • I tested this PR with a High Traffic account against the staging or production API to ensure there are no regressions (e.g. long loading states that impact usability).
• I included screenshots or videos for tests on all platforms
• I ran the tests on all platforms & verified they passed on:
  • Android: Native
  • Android: mWeb Chrome
  • iOS: Native
  • iOS: mWeb Safari
  • MacOS: Chrome / Safari
• I verified there are no console errors (if there's a console error not related to the PR, report it or open an issue for it to be fixed)
• I followed proper code patterns (see Reviewing the code)
  • I verified that comments were added to code that is not self explanatory
  • I verified that any new or modified comments were clear, correct English, and explained "why" the code was doing something instead of only explaining "what" the code was doing.
  • I verified any copy / text that was added to the app is grammatically correct in English. It adheres to proper capitalization guidelines (note: only the first word of header/labels should be capitalized), and is either coming verbatim from figma or has been approved by marketing (in order to get marketing approval, ask the Bug Zero team member to add the Waiting for copy label to the issue)
• If a new code pattern is added I verified it was agreed to be used by multiple Expensify engineers
• I followed the guidelines as stated in the Review Guidelines
• I tested other components that can be impacted by my changes (i.e. if the PR modifies a shared library or component like Avatar, I verified the components using Avatar are working as expected)
• If a new CSS style is added I verified that:
  • A similar style doesn't already exist
  • The style can't be created with an existing StyleUtils function (i.e. StyleUtils.getBackgroundAndBorderStyle(theme.componentBG))
• If new assets were added or existing ones were modified, I verified that:
  • The assets are optimized and compressed (for SVG files, run npm run compress-svg)
  • The assets load correctly across all supported platforms.
• If the PR modifies code that runs when editing or sending messages, I tested and verified there is no unexpected behavior for all supported markdown - URLs, single line code, code blocks, quotes, headings, bold, strikethrough, and italic.
• If the PR modifies a generic component, I tested and verified that those changes do not break usages of that component in the rest of the App (i.e. if a shared library or component like Avatar is modified, I verified that Avatar is working as expected in all cases)
• If the PR modifies a component related to any of the existing Storybook stories, I tested and verified all stories for that component are still working as expected.
• If the PR modifies a component or page that can be accessed by a direct deeplink, I verified that the code functions as expected when the deeplink is used - from a logged in and logged out account.
• If the PR modifies the UI (e.g. new buttons, new UI components, changing the padding/spacing/sizing, moving components, etc) or modifies the form input styles:
  • I verified that all the inputs inside a form are aligned with each other.
  • I added Design label and/or tagged @Expensify/design so the design team can review the changes.
• I added unit tests for any new feature or bug fix in this PR to help automatically prevent regressions in this user flow.
• If the main branch was merged into this PR after a review, I tested again and verified the outcome was still expected according to the Test steps.

Screenshots/Videos

Android: Native

Android: mWeb Chrome

iOS: Native

iOS: mWeb Safari

MacOS: Chrome / Safari

[stephanieelliott]

@c3024, please review the files changed and confirm they reflect the current behavior. Then post a new comment saying @MelvinBot mark this PR as ready for review.

Bump on this @c3024!

[MelvinBot]

🤖 Web test steps verification results: ⚠️ partial

While we wait on c3024, I checked the two doc changes against the live app and the current code. The paid-by: operator, the Paid by filter row, and the Paid by column entry all exist and are labeled exactly as documented. The one thing I could not exercise live is the blank-until-paid cell, because the test account has no reports — the code confirms it.

Step	Status
VERIFY 1: 'Paid by' entry exists and can be enabled in Reports column picker Display > Edit columns list contains a button/checkbox labeled exactly "Paid by"; clicking it and Save persisted the change (Reset columns link appeared, confirming a non-default state was saved).	✅
VERIFY 2: Column header reads 'Paid by' and the cell is blank for unpaid reports Test account has zero reports; the Reports view only shows the "No reports yet" empty state (no header row, no cells) both before and after enabling the column. Not verifiable live without seeding data, which is out of scope for a read-only run.	❌
VERIFY 3: 'paid-by:' typed in the search bar is accepted as an operator with member suggestions Typing paid-by: produced autocomplete options including paid-by: and paid-by:me, so the operator is recognized and offers member completion rather than being treated as free text.	✅
VERIFY 4: Filters panel has a row labeled exactly 'Paid by' The Filters panel lists a "Paid by" row between "To" and "Date"; selecting it opens an is / is not toggle plus a member picker.	✅

Code check of each claim in the diff

• paid-by: is the operator syntax — src/CONST/index.ts:7645 and the grammar accepts both paidBy and paid-by case-insensitively at src/libs/SearchParser/baseRules.peggy:35-37.
• Works on expense, invoice and trip searches too — PAID_BY is in the filter list for all four data types: expense, expense report, invoice, trip (src/hooks/useAdvancedSearchFilters.ts:33, :84, :117, :158).
• Member values (email, phone, display name, me) — PAID_BY is grouped with the other user filters that resolve display names and logins to accounts (src/CONST/index.ts:9648), and the live autocomplete offered paid-by:me.
• Comma-combined values — filter values parse as a comma-separated list in src/libs/SearchParser/searchParser.peggy:323.
• Column is on the Reports view only — PAID_BY appears in the expense-report custom columns (src/CONST/index.ts:7253) and not in the search/expense column availability list, which matches the wording in the diff.
• Blank until the report is paid — the value comes from the actor on the latest payment action and is empty when there is none (src/libs/SearchUIUtils.ts:3148-3152). This covers the VERIFY 2 gap above.
• Label is exactly "Paid by" — src/components/Search/SearchTableHeader.tsx:268-269 → src/languages/en.ts:9499.

c3024 — every claim in the diff holds up against the current code and app, so this should be a quick confirm. Once you're happy, reply with @MelvinBot mark this PR as ready for review and I'll flip it. I have not marked it ready myself, since the review confirmation is yours to give.

---

view run · no recording available

[c3024]

@MelvinBot please merge main and resolve the conflicts. Drop the change to Using-Reports-in-New-Expensify.md, because PR 100057 already documents the Paid by column there. In Use-Search-Operators-to-Filter-and-Analyze.md, the report operators are now a table, so add paid-by: as a table row directly after paid-status:, keeping the same content.

[MelvinBot]

Merged main and resolved the conflicts. The PR is now MERGEABLE and down to a single changed file.

What I did:

• Using-Reports-in-New-Expensify.md — dropped entirely. Took main verbatim, so this PR no longer touches the file. main already carries the Paid by column and filter docs from [No QA] Docs updates for E/A#99911 Refresh the Spend article for the current Filters and Display controls, including the keywords.
• Use-Search-Operators-to-Filter-and-Analyze.md — reformatted as a table row. main converted the report operator list into a table, so paid-by: is now a row directly after paid-status:, with the same content. The e.g. value moved into the Example column to match how the paid-status: row above it is written.
• Keywords: kept both sides — main's transaction status filter, pending card expenses, posted card expenses plus this PR's paid by filter, paid-by.

The full remaining diff is the two lines below:

-keywords: [..., transaction status filter, pending card expenses, posted card expenses]
+keywords: [..., transaction status filter, pending card expenses, posted card expenses, paid by filter, paid-by]

 | `paid-status:` | Filter by how the report was paid (`markedAsPaid`, `withdrawing`, `confirmed`). Combine multiple values with commas | `paid-status:markedAsPaid,confirmed` |
+| `paid-by:` | Filter by the member who paid the report (email, phone, display name, or `me`). Combine multiple members with commas. Reports that have not been paid never match. This operator also works on expense, invoice, and trip searches | `paid-by:me,alice@acme.com` |
 | `action:` | Filter by blocking report action | `action:approve` |

Merge and test details

Merge commit 5dd7e003ea83, created with git merge origin/main — no rebase, squash, or force-push. main was at 1e3ca2f379ac. Those two articles were the only conflicting files in the whole merge.

I could not run cspell locally (blocked in this environment), so CI will be the check. The risk is nil: the added row introduces no new vocabulary, and alice@acme.com and Acme already appear in this same article in the from: and workspace: rows.

No docs were added or removed, so createDocsRoutes.sh routing is unaffected.

The Tests and QA Steps sections in the PR body are still the human-only TODOs — I did not fill those in.

---

c3024 — this is ready for another look. Reply with @MelvinBot mark this PR as ready for review when you're happy with it.

[c3024]

@MelvinBot mark the PR as ready for review.

[OSBotify]

A preview of your ExpensifyHelp changes have been deployed to https://37929090.helpdot.pages.dev ⚡️

Updated articles:

• articles/new-expensify/reports-and-expenses/Use-Search-Operators-to-Filter-and-Analyze

[melvin-bot]

Concierge reviewer checklist:

• I have verified the accuracy of the article
  • The article is within a hub that makes sense, and the navigation is correct
  • All processes, screenshots, and examples align with current product behavior.
  • All links within the doc have been verified for correct destination and functionality.
• I have verified the readability of the article
  • The article's language is clear, concise, and free of jargon.
  • The grammar, spelling, and punctuation are correct.
  • The article contains at least one image, or that an image is not necessary
• I have verified the formatting of the article
  • The article has consistent formatting (headings, bullet points, etc.) with other HelpDot articles and that aligns with the HelpDot formatting standards.
  • The article has proper text spacing and breaks for readability.
• I have verified the article has the appropriate tone and style
  • The article's tone is professional, friendly, and suitable for the target audience.
  • The article's tone, terminology, and voice are consistent throughout.
• I have verified the overall quality of the article
  • The article is not missing any information, nor does it contain redundant information.
  • The article fully addresses user needs.
• I have verified that all requested improvements have been addressed

For more detailed instructions on completing this checklist, see How do I review a HelpDot PR as a Concierge Team member?

cc @Kel-Expensify

[melvin-bot]

@Kel-Expensify Please copy/paste the Reviewer Checklist from here into a new comment on this PR and complete it. If you have the K2 extension, you can simply click: [this button]

[MelvinBot]

Marked as ready for review. ✅

I also corrected two things that went stale after the main merge, since they'd have misled a reviewer:

• Title — dropped "and column". It read ... Document Paid by search filter and column, but the column change is no longer in this PR.
• Description — the Explanation of Change still described edits to two articles, including the Paid by column in Using-Reports-in-New-Expensify.md. It now describes the one article that actually changes, and says explicitly that the column docs were dropped in favour of [No QA] Docs updates for E/A#99911 Refresh the Spend article for the current Filters and Display controls.

Checks: everything passes except Check independent approval, which just needs your review. Notably spellcheck passed, which closes the one gap I flagged last time when cspell couldn't run locally.

I did not run an app test — this PR only changes a markdown help article, so there's no app behavior to verify. The paid-by: operator itself was already verified against the live app when the PR was written.

Current state

• isDraft: false, mergeable: MERGEABLE
• One changed file: docs/articles/new-expensify/reports-and-expenses/Use-Search-Operators-to-Filter-and-Analyze.md
• mergeStateStatus: BLOCKED is just the pending-approval gate

I left the Tests and QA Steps sections alone — those are yours to fill in, and both still carry the // TODO placeholder. The PR is labelled [No QA], so you may want to replace the QA placeholder with an explicit N/A.

[github-actions]

HelpDot Documentation Review test placeholder

[c3024]

@stephanieelliott, I verified the changes. Please have a look.

[github-actions]

HelpDot Documentation Review

Overall Assessment
This PR adds a single paid-by: row to the report operators table in Use-Search-Operators-to-Filter-and-Analyze.md, plus two related keywords (paid by filter, paid-by) in the frontmatter. It documents a previously undiscoverable search operator. The change is small, surgical, and slots into an existing table without altering structure or headings.

Scores Summary

• Readability: 9/10 - The new row is clear and self-contained. It explains the value formats (email, phone, display name, me), comma-combining behavior, the unpaid-reports edge case, and cross-search applicability in one concise cell that mirrors the phrasing of neighboring rows.
• AI Readiness: 9/10 - Keywords were extended to match real "paid by" search intent, and internalScope remains accurate for the added content. No new headings were introduced, so the single-title and task-based heading rules are unaffected.
• Style Compliance: 9/10 - Operator syntax, casing, and description style exactly match adjacent rows (e.g. paid-status:). The row is correctly placed after paid-status: to keep payment operators grouped. Member terminology is used correctly. No UI-labeling rules are triggered since this is a syntax table, not a navigation instruction.

Key Findings

• Positive: The change respects the one-workflow-per-article rule by extending an existing table rather than creating a redundant article, and the PR description confirms the overlapping Paid by column doc was correctly dropped in favor of the companion PR.
• Positive: Edge-case behavior (unpaid reports never match) and scope (works on expense, invoice, and trip searches) are documented, which improves retrieval quality.
• Minor: The example paid-by:me,alice@acme.com is adequate but is a reports-table example only; the description does note broader applicability, so this is not blocking.

Recommendations

• No blocking changes required. Optionally, confirm the example value formats (me, email) render consistently with how the app displays them, per the exact-UI-terminology rule.
• Ensure the human co-author completes the Tests/QA sections before marking ready for review (currently TODO placeholders).

Files Reviewed

• docs/articles/new-expensify/reports-and-expenses/Use-Search-Operators-to-Filter-and-Analyze.md - One table row and two keywords added. Compliant with governance; approved with only minor optional suggestions.

Note: Detailed line-by-line feedback has been provided as inline comments.

[OSBotify]

🚀 Deployed to staging by https://github.com/stephanieelliott in version: 9.4.95-0 🚀

platform	result
🕸 web 🕸	success ✅
🤖 android 🤖	success ✅
🍎 iOS 🍎	success ✅

[OSBotify]

🚀 Deployed to production by https://github.com/Julesssss in version: 9.4.95-4 🚀

platform	result
🕸 web 🕸	success ✅
🤖 android 🤖	failure ❌
🍎 iOS 🍎	failure ❌