`updateCustomBenefit` does not update BenefitDetail on related Screener
Maintainers usually reply within 1 day
Nobody has claimed this yet.
Assessment
- Difficulty
- 3/5
- Estimated time
- 1-2 days
- Newbie friendliness
- 45/100
Research direction
Start at updateCustomBenefit(...) and trace how the corresponding Screener BenefitDetail is located and persisted. Compare the Custom Benefit name and description with the related BenefitDetail, then verify that updates keep those fields synchronized without breaking the existing fast lookup behavior.
Written by the indexing model from the issue text.
Description
Bug
- Currently, updates to Custom Benefit fields such as
nameordescriptionviaupdateCustomBenefit(...)do not also change the same fields on the correspondingBenefitDetail.
Notes
- The purpose of having BenefitDetails on the Screener model is to allow us to get the name/descriptions of Custom Benefits related to a Screener quickly without having to individually query for each one. This allows the List page for Custom Benefits in a Screener to load more quickly than it otherwise would.
- It may be worth examining if there is a feature or strategy we can leverage to maintain this speed without having two sources of truth for fields like Custom Benefit name/description that need to be kept in-sync.
- Dominant language
- Java
- Stars
- 16
- Forks
- 5
- Avg merge
- 1d 26m
- Merged PRs (30d)
- 25
Getting set up
We have not checked this project's setup files yet. Start from its README, and see our first-contribution guide for the general steps.
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
More from CodeForPhilly/benefit-decision-toolkit
-
documentation Good for newcomer quick win
Difficulty 2/5 1-3 hours Newbie friendliness 68/100
CodeForPhilly/benefit-decision-toolkit#519 ·
Maintainers usually reply within 1 day
-
documentation quick win
Difficulty 2/5 1-3 hours Newbie friendliness 68/100
CodeForPhilly/benefit-decision-toolkit#445 ·
Maintainers usually reply within 1 day
-
Make issue templatesOpen
Difficulty 2/5 1-3 hours Newbie friendliness 65/100
CodeForPhilly/benefit-decision-toolkit#425 ·
Maintainers usually reply within 1 day
-
Difficulty 4/5 3-5 days Newbie friendliness 48/100
CodeForPhilly/benefit-decision-toolkit#525 ·
Maintainers usually reply within 1 day
-
Difficulty 4/5 3-5 days Newbie friendliness 45/100
CodeForPhilly/benefit-decision-toolkit#524 ·
Maintainers usually reply within 1 day
All issues in CodeForPhilly/benefit-decision-toolkit
Similar issues
-
Difficulty 2/5 1-3 hours Newbie friendliness 88/100
refinedmods/refinedstorage2#1414 · 1 comment ·
-
bug
Difficulty 2/5 1-3 hours Newbie friendliness 78/100
-
In Java's `LongBoundedSum`, setting `lower` to `Long.MIN_VALUE` under-estimates the sensitivityOpen
Difficulty 2/5 1-3 hours Newbie friendliness 73/100
google/differential-privacy#489 ·
-
Difficulty 1/5 Under an hour Newbie friendliness 78/100
Maintainers usually reply within 1 day
-
link-check link-check:manual
Difficulty 2/5 1-3 hours Newbie friendliness 85/100