Hacktoberfest 2026: the issues maintainers tagged for October, open and beginner-friendly. Browse Hacktoberfest issues

Let one screener answer fill several check inputs

Open
  • Is something wrong?
#569 0 comments 0 reactions 0 assignees View on GitHub

Maintainers usually reply within 1 day

Nobody has claimed this yet.

Assessment

Difficulty
5/5
Estimated time
Over a week
Newbie friendliness
35/100
Issue type
Feature
Clarity
Mostly clear
Activity status
Active
Tech stack
java
Domain
api, backend

Research direction

Start by tracing InputSchemaService.transformIncomeAssessmentsSchema and FormDataTransformer.expandIncomeAssessments, the existing special case introduced by PR #549. Follow how form-js field keys and check input paths control answered-question hiding, then inspect the AI drafting prompt. Done means a general binding approach supports copied and derived answers and makes the approximation visible in results; the issue leaves those design choices open.

Written by the indexing model from the issue text.

Description

backend frontend

Problem

The builder asks exactly one question per unique input path. When checks need the same fact under different paths, screeners repeat questions. For example, one check might read people.client.dateOfBirth while another reads an age, or programs might prepare the same household's income under different rules.

Branch #549 added a special case for income. Library checks key incomeAssessments by program basis (paLiheap, pecoCap, …). The builder asks incomeAssessments.annualIncome and incomeAssessments.householdSize once (InputSchemaService.transformIncomeAssessmentsSchema) and copies the answers to every basis before evaluation (FormDataTransformer.expandIncomeAssessments). Without that, a screener with every utility benefit would ask for income seven times.

Goal

Generalize this so one form field can supply several input paths, either declared by the library (path equivalences or derivations) or chosen in the builder. AI drafting could then reduce questions across benefits instead of only ordering them.

Considerations

  • A shared answer approximates programs whose rules differ, such as income exclusions or household membership. Decide when that approximation is acceptable and how results should communicate it.
  • Bindings involve form-js field keys, FormDataTransformer, the check input paths used to hide answered questions, and the AI drafting prompt.
  • Derived values (age from date of birth) differ from copied values (the same income for several bases).
Dominant language
Java
Stars
16
Forks
5
Avg merge
16h 37m
Merged PRs (30d)
20

Getting set up

Open in Codespaces

Starts the project's dev container in your browser, under your own GitHub account.

  • No Dockerfile or Docker Compose file
  • Has a pull request template
  • No contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from CodeForPhilly/benefit-decision-toolkit

All issues in CodeForPhilly/benefit-decision-toolkit

Similar issues

More Java issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.