Refactor PhlSeniorCitizenTaxFreeze to use new checks#390
Merged
prestoncabe merged 1 commit intoMar 21, 2026
Merged
Conversation
This wires up the following checks to the SCTF library benefit: - OwnerOccupant - LivesInPhiladelphiaPa The remaining eligibility check for this is a complex age requirement. It is implemented in the SCTF library benefit DMN. I intend to implement it as a custom check as part of #339 . The complex age requirement raised some interesting questions about how to implement similar checks in the future. We will likely eventually need to have better solutions for: - How might we share data facts between library and custom checks? - We discussed possibly using the same "situation" input across library and custom checks. - We also discussed finding a way to use the same data shape for all three of: custom checks/form editor/library checks - Another related feature that will help: supporting library benefits in the web app. This is another route to allowing users to bypass complex/bespoke benefit logic. - How might we access library checks from within custom checks? - There are a few different approaches from backend and UX standpoint we could take with this - This is probably blocked until we figure out the data sharing question I'm punting/letting go of the above questions for now because of two recent realizations: - In the set of 5 property tax relief benefits, there are no age-related requirements except for SCTF. So, we don't need to solve the data-sharing question right now. - There is a simple enough workaround to sharing data between custom and library checks that I wasn't considering before: mapping data in the form editor using the Expression Component (e.g. setting `custom.clientDateOfBirth` to `people.client.dateOfBirth`). Ideal? No. But simple enough that I think it buys us time to finish the Prototype v2 milestone, get this in front of users, and prioritize a long-term solution based on their feedback.
prestoncabe
force-pushed
the
297-complete-library-checks-for-the-phlseniorcitizentaxfreeze-benefit
branch
from
March 21, 2026 15:02
d372446 to
5864b4b
Compare
Collaborator
Author
|
@Justin-MacIntosh @Michael-Dratch See my notes above for my latest thinking on the question of data sharing between custom checks and library checks. |
prestoncabe
deleted the
297-complete-library-checks-for-the-phlseniorcitizentaxfreeze-benefit
branch
March 21, 2026 15:27
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
This wires up the following checks to the SCTF library benefit:
The remaining eligibility check for this is a complex age requirement. It is implemented in the SCTF library benefit DMN. I intend to implement it as a custom check as part of #339 .
The complex age requirement raised some interesting questions about how to implement similar checks in the future. We will likely eventually need to have better solutions for:
I'm punting/letting go of the above questions for now because of two recent realizations:
custom.clientDateOfBirthtopeople.client.dateOfBirth). Ideal? No. But simple enough that I think it buys us time to finish the Prototype v2 milestone, get this in front of users, and prioritize a long-term solution based on their feedback.