Better UX for mapping form inputs to eligibility checks
I maintainer di solito rispondono entro 1 giorno
Nessuno ha ancora preso questa issue.
Valutazione
- Difficoltà
- 5/5
- Tempo stimato
- Più di una settimana
- Idoneità per principianti
- 35/100
- Tipo di issue
- Funzionalità
- Chiarezza
- Da chiarire
- Stato di attività
- Tranquilla
- Ambito
- frontend
Direzione di ricerca
Inizia dalla sezione Components dell’editor dei moduli ed esamina l’issue #357 insieme al comportamento attuale del mapping nel ramo principale. Chiarisci le due modalità o schede proposte, il loro comportamento di validazione e cosa significa il completamento sia per i flussi di lavoro incentrati sui moduli sia per quelli incentrati sull’idoneità.
Scritto dal modello di indicizzazione a partire dal testo della issue.
Descrizione
Originally surfaced by #357
There is a "chicken or egg" issue when creating the form and sometimes you want to focus on the questions and sometimes you want to focus on ensuring all eligibility checks are accounted for.
Idea:
Allow the user to toggle between "modes". One mode where the eligibility checks are less emphasized but with a way to validate mapping t to form inputs (this is the current functionality in main branch) and another mode that is focused on the eligibility checks with the form possible form inputs that could be implemented for them (this is the concept presented in #357).
This could take the form of two different tabs in the "Components" section of the form editor; one that shows all components, the other that allows you to select/map only the components that are possible for a given (selected) eligibility check.
- Lingua principale
- Java
- Stelle
- 16
- Fork
- 5
- Merge medio
- 17h 24m
- PR unite (30g)
- 23
Preparare l'ambiente
Avvia il container di sviluppo del progetto nel browser, con il tuo account GitHub.
- Nessun Dockerfile né file Docker Compose
- Ha un modello di pull request
- Nessuna guida per i contributori
Come iniziare
- Leggi tutta la issue e poi la guida ai contributi del progetto.
- Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
- Fai un fork del repository e lavora su un branch.
- Apri una pull request che faccia riferimento al numero della issue.
Altre issue di CodeForPhilly/benefit-decision-toolkit
-
documentation Good for newcomer quick win
Difficoltà 2/5 1-3 ore Idoneità per principianti 68/100
CodeForPhilly/benefit-decision-toolkit#519 ·
I maintainer di solito rispondono entro 1 giorno
-
documentation quick win
Difficoltà 2/5 1-3 ore Idoneità per principianti 68/100
CodeForPhilly/benefit-decision-toolkit#445 ·
I maintainer di solito rispondono entro 1 giorno
-
Make issue templatesAperta
Difficoltà 2/5 1-3 ore Idoneità per principianti 65/100
CodeForPhilly/benefit-decision-toolkit#425 ·
I maintainer di solito rispondono entro 1 giorno
-
Difficoltà 4/5 3-5 giorni Idoneità per principianti 48/100
CodeForPhilly/benefit-decision-toolkit#525 ·
I maintainer di solito rispondono entro 1 giorno
-
Difficoltà 4/5 3-5 giorni Idoneità per principianti 45/100
CodeForPhilly/benefit-decision-toolkit#524 ·
I maintainer di solito rispondono entro 1 giorno
Tutte le issue di CodeForPhilly/benefit-decision-toolkit
Issue simili
-
Difficoltà 2/5 1-3 ore Idoneità per principianti 88/100
I maintainer di solito rispondono entro 1 giorno
-
Difficoltà 2/5 1-3 ore Idoneità per principianti 88/100
I maintainer di solito rispondono entro 1 giorno
-
go 🏃 testing 🧪
Difficoltà 2/5 1-3 ore Idoneità per principianti 78/100
valkey-io/valkey-glide#7239 ·
I maintainer di solito rispondono entro 2 giorni
-
bug
Difficoltà 2/5 1-3 ore Idoneità per principianti 88/100
I maintainer di solito rispondono entro 1 giorno
-
Difficoltà 2/5 1-3 ore Idoneità per principianti 76/100
github/copilot-sdk#2793 ·
I maintainer di solito rispondono entro 1 giorno