You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
[Due for payment 2026-10-27] [Insights: Violations][R2] Add the date filter any-approval #99930
Part of the [Tracking] [Insights Violations] Release 2 issue: Expensify/Expensify#671675
Phase 6 of the Release 2 implementation order. Depends on Phase 3: Expensify/Expensify#676895 (any-approval date filter - Auth).
The largest App phase by file count.
Problem
approved is already wired end to end in App and any-approval needs the same wiring, otherwise the suggested search cannot express its date range.
Solution
Every step sits next to the equivalent approved entry.
Add ANY_APPROVAL: 'any-approval' to SYNTAX_FILTER_KEYS.
Add the five form keys ANY_APPROVAL_ON, ANY_APPROVAL_NOT, ANY_APPROVAL_AFTER, ANY_APPROVAL_BEFORE and ANY_APPROVAL_RANGE to FILTER_KEYS, and repeat them everywhere the APPROVED_* keys appear in SearchAdvancedFiltersForm.ts.
Map each new form key in FILTER_TO_SYNTAX_KEY, and add a FILTER_VIEW_MAP entry with labelKey: 'search.filters.anyApproval' and an icon.
Add the autocomplete cases in SearchAutocompleteUtils and useAutocompleteSuggestions, and add the key to the SYNTAX_FILTER_KEYS.APPROVED lists in useAdvancedSearchFilters.
Add the parser rule in baseRules.peggy and the rule name to the key lists in searchParser.peggy and autocompleteParser.peggy, then re-run npm run generate-search-parser and npm run generate-autocomplete-parser and commit the generated files.
Add the search.filters.anyApproval translation in en.ts and every other language file.
Tests
Automated and manual tests from the doc section must be included in the PR. Key automated cases: buildQueryStringFromFilterFormValues and buildFilterFormValuesFromQuery round-trip the ON, AFTER, BEFORE, RANGE and negated forms; the autocomplete suggests date presets after any-approval:; and the parser accepts any-approval in a query string, which also proves the parsers were regenerated and committed.
changed the title [-][HOLD 676895][Insights: Violations][R2] Add the date filter any-approval - App[/-][+][HOLD 676895][Insights: Violations][R2] Add the date filter any-approval[/+]on Aug 31, 2026
changed the title [-][HOLD 676895][Insights: Violations][R2] Add the date filter any-approval[/-][+][Insights: Violations][R2] Add the date filter any-approval[/+]on Sep 22, 2026
P.S. Is everyone reading this sure this is really a near-term priority? Be brave: if you disagree, go ahead and close it out. If someone disagrees, they'll reopen it, and if they don't: one less thing to do!
[Contributor] The offending PR and associated issue have been commented on, pointing out the bug it caused and why, so the author and reviewers can learn from the mistake.
Link to the comment on the PR: N/A
[Contributor] If the regression was CRITICAL (e.g. interrupts a core flow) A discussion in #expensify-open-source has been started about whether any other steps should be taken (e.g. updating the PR review checklist) in order to catch this type of bug sooner.
Link to discussion:
[Contributor] If it was decided to create a regression test for the bug, please propose the regression test steps using the template below to ensure the same bug will not reach production again.
[BugZero Assignee] Create a GH issue for creating/updating the regression test once above steps have been agreed upon.
Link to issue:
Regression Test Proposal
Precondition:
Test:
Open the advanced filters and verify "Any approval" appears with a date picker, set it to last month, and verify the query text reads any-approval:last-month
Type any-approval: or anyApproval: in the search bar and verify the date presets autocomplete
Verify the results only include expenses approved or forwarded in the period
changed the title [-][Insights: Violations][R2] Add the date filter any-approval[/-][+][Due for payment 2026-10-27] [Insights: Violations][R2] Add the date filter any-approval[/+]on Oct 20, 2026
The solution for this issue has been 🚀 deployed to production 🚀 in version 9.5.14-3 and is now subject to a 7-day regression period 📆. Here is the list of pull requests that resolve this issue:
If no regressions arise, payment will be issued on 2026-10-27. 🎊
The following checklist (instructions) will need to be completed before the issue can be closed. Please copy/paste the Contributor+ Checklist from here into a new comment on this GH and complete it. If you have the K2 extension, you can simply click: [this button]. If no checklist is needed for this issue, you can click: [no checklist button]
Activity
nkdengineer commentedon Aug 31, 2026
Comment for assignment.
[-][HOLD 676895][Insights: Violations][R2] Add the date filter any-approval - App[/-][+][HOLD 676895][Insights: Violations][R2] Add the date filter any-approval[/+]daledah commentedon Aug 31, 2026
Comment for being assigned as the reviewer for this issue
[-][HOLD 676895][Insights: Violations][R2] Add the date filter any-approval[/-][+][Insights: Violations][R2] Add the date filter any-approval[/+]neil-marcellini commentedon Sep 22, 2026
@nkdengineer this is off hold now. Please start implementation.
nkdengineer commentedon Sep 23, 2026
@neil-marcellini I still see the backend error while testing.
neil-marcellini commentedon Sep 23, 2026
Resolved as mentioned in DM. It should be
anyApprovalwhen sent to the API. Sorry for the mistake in the issue description.1 remaining item
nkdengineer commentedon Sep 24, 2026
@daledah The PR is ready for review.
melvin-bot commentedon Oct 19, 2026
This issue has not been updated in over 15 days. @neil-marcellini, @nkdengineer, @daledah eroding to Monthly issue.
P.S. Is everyone reading this sure this is really a near-term priority? Be brave: if you disagree, go ahead and close it out. If someone disagrees, they'll reopen it, and if they don't: one less thing to do!
nkdengineer commentedon Oct 20, 2026
The PR was merged.
daledah commentedon Oct 20, 2026
BugZero Checklist:
[Contributor] The offending PR and associated issue have been commented on, pointing out the bug it caused and why, so the author and reviewers can learn from the mistake.
Link to the comment on the PR: N/A
[Contributor] If the regression was CRITICAL (e.g. interrupts a core flow) A discussion in #expensify-open-source has been started about whether any other steps should be taken (e.g. updating the PR review checklist) in order to catch this type of bug sooner.
Link to discussion:
[Contributor] If it was decided to create a regression test for the bug, please propose the regression test steps using the template below to ensure the same bug will not reach production again.
[BugZero Assignee] Create a GH issue for creating/updating the regression test once above steps have been agreed upon.
Link to issue:
Regression Test Proposal
Precondition:
Test:
Do we agree 👍 or 👎
[-][Insights: Violations][R2] Add the date filter any-approval[/-][+][Due for payment 2026-10-27] [Insights: Violations][R2] Add the date filter any-approval[/+]melvin-bot commentedon Oct 20, 2026
@nkdengineer / @daledah
The solution for this issue has been 🚀 deployed to production 🚀 in version 9.5.14-3 and is now subject to a 7-day regression period 📆. Here is the list of pull requests that resolve this issue:
If no regressions arise, payment will be issued on 2026-10-27. 🎊
The following checklist (instructions) will need to be completed before the issue can be closed. Please copy/paste the Contributor+ Checklist from here into a new comment on this GH and complete it. If you have the K2 extension, you can simply click: [this button]. If no checklist is needed for this issue, you can click: [no checklist button]