Repository navigation
[Due for payment 2026-10-30] [Rules Engine Release 1] [App] Migrate the frontend to support the new rules engine for Merchant Rules #100300
Description
We're in the process of migrating all of our rules into one place, with one format. Lets start by migrating merchant rules to use these new data formats and APIs
We will implement all of the sub-issues to this issue, in the order that they are listed
Activity
[-]Migrate the frontend to support the new rules engine for Merchant Rules[/-][+][Rules Engine Release 1] Migrate the frontend to support the new rules engine for Merchant Rules[/+]Krishna2323 commentedon Sep 3, 2026
@JS00001 a few things aren't clear to me before I can start:
1. Do category tax defaults migrate too? They're in
policy.rules.expenseRules, but they have aCreateTransactiontrigger and aSetaction, so they match your definition of an Expense Default Rule. This also affects #99420.2. Will the backend keep writing
policy.rules.codingRulesduring the switch? If old rules get backfilled whilecodingRulesstays populated, every rule will show up twice. Is this a hard cutover, or will both paths coexist during the beta? Also do we even have beta for this? 😅3. Leaf nodes use
op, while the branch usesoperator. OurASTNodeusesoperatoreverywhere. Is this a typo, or is this format different from search's AST?4.
notContainsisn't inCONST.SEARCH.SYNTAX_OPERATORS. Is it being added, or should this beneq?5. There's no
UpdateRule. Is editing a rule justSetRulewith the sameruleID?6.
rightis an array, but our filter hasrightas a string. Does an array mean multiple values OR'd together, and can a merchant have more than one?7. The
actionslist skipscomment(Description) andvendorID. Both have live UI pages today. Are they being dropped, or just left out of the example?JS00001 commentedon Sep 3, 2026
Lets keep this out of scope to start with, while we get the FE working. But then yes, eventually they will be migrated to the new format
No, we will not be writing to
codingRulesanymore. We are doing the inverse. Currently, every call toSetPolicyCodingRuleis writing to the new rules format as well as the legacy one.Sorry, I'm used to using op haha, its
operator, updatedThis is a new operator. We don't use it in the FE, but we support it now. We support
neqandnotContainsYes, use
SetRulefor thisYes, an array is an
OR, the value of filters can be an array or a string (or a number for other filters), either of them worksSorry, comment is also a valid property. We don't support vendorID yet because thats still in progress, we will support that before this feature goes live, so lets add vendorID here as well
Krishna2323 commentedon Sep 7, 2026
@JS00001 @luacmartins who’ll review the PR? I’m going to open it for review shortly.
Edit: PR is ready for review!
JS00001 commentedon Sep 9, 2026
@Krishna2323 Can we modify the PR slightly? After discussing w/ Carlos & Carlos, here's the approach that we want to take on the FE to prevent regressions
GetRules, and make merchant rules read from therules_collection. We should not useSetRuleorDeleteRuleyet. This is becauseSetPolicyCodingRulewrites to the new rules storage, butSetRuledoes not write backwards. This could lead to older clients not seeing rules that were created viaSetRulerules_collectionSetRulecommand instead ofSetPolicyCodingRuleJS00001 commentedon Sep 23, 2026
@Krishna2323 would you be able to branch off of your above PR to get started on
3. We now use the SetRule command instead of SetPolicyCodingRulewhile the PR above is in review?Krishna2323 commentedon Sep 23, 2026
Yes, I’ll start that shortly after resolving the comments on the current PR.
19 remaining items
JS00001 commentedon Oct 7, 2026
We are done with these sub-issues for now, I left the two FE issues open for payment, moving onto release 2 now
jponikarchuk commentedon Oct 9, 2026
Deploy Blocker #103555 was identified to be related to the PR #102106 that attempted to fix this issue.
melvin-bot commentedon Oct 9, 2026
If you are the assigned CME please investigate whether the linked PR caused a regression and leave a comment with the results.
If a regression has occurred and you are the assigned CM follow the instructions here.
If this regression could have been avoided please consider also proposing a recommendation to the PR checklist so that we can avoid it in the future.
[-][Due for payment 2026-10-12] [Rules Engine Release 1] [App] Migrate the frontend to support the new rules engine for Merchant Rules[/-][+][Due for payment 2026-10-16] [Rules Engine Release 1] [App] Migrate the frontend to support the new rules engine for Merchant Rules[/+]melvin-bot commentedon Oct 9, 2026
@Krishna2323 / @situchan
The solution for this issue has been 🚀 deployed to production 🚀 in version 9.5.6-6 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-16. 🎊
[-][Due for payment 2026-10-16] [Rules Engine Release 1] [App] Migrate the frontend to support the new rules engine for Merchant Rules[/-][+][Due for payment 2026-10-30] [Rules Engine Release 1] [App] Migrate the frontend to support the new rules engine for Merchant Rules[/+]melvin-bot commentedon Oct 23, 2026
@Krishna2323 / @situchan
The solution for this issue has been 🚀 deployed to production 🚀 in version 9.5.18-1 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-30. 🎊
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]