fix(modal-fields): render user fields assigned to the basic group (issue #2045)#2052
Open
ther12k wants to merge 1 commit into
Open
fix(modal-fields): render user fields assigned to the basic group (issue #2045)#2052ther12k wants to merge 1 commit into
ther12k wants to merge 1 commit into
Conversation
…sue callumalpass#2045) When a user assigned a custom (user-typed) field to the 'Basic Information' group via the Modal Fields settings, the field silently disappeared. The cause was a hardcoded skip in renderTaskModalFieldGroups: if (groupConfig.id === 'basic') { continue; } The skip was originally added to avoid double-rendering the built-in basic fields (title, details), which have dedicated creation paths in TaskModal (createTitleInput, detailsMarkdownEditor). Unfortunately, the same skip also discarded any user field the user moved into the basic group. This change: 1. Removes the hardcoded basic-group skip. 2. Relies on the existing renderTaskModalField dispatcher to silently drop core basic fields (they are not in fieldRenderers, and they are not user fields, so renderTaskModalField returns false and they get counted in ignoredFieldIds). Their UI surfaces remain unchanged because the dedicated creation paths still run elsewhere. 3. Lets user fields in the basic group render through renderUserField exactly like they do in every other group. 4. Adds a guard at the end of the group loop that removes an empty task-modal__field-group container when the group produced zero rendered fields. This keeps the DOM clean for the basic group when it contains only core fields, and is also defensive against any future group whose fields are all core-only. Updates tests/unit/modals/taskModalFieldRenderer.test.ts to reflect the new (correct) behavior — the previous expectations encoded the bug. Both tests now correctly report title/details as ignored, and assert that empty group containers are removed. Adds tests/unit/issues/issue-2045-user-fields-in-basic-group.test.ts with three cases: - user field moved into the basic group renders through renderUserField - groups whose fields all render keep their container (no regression) - core-only basic group produces no leftover empty container Closes callumalpass#2045
This was referenced Jun 21, 2026
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.
Summary
When a user assigns a custom (user-typed) field to the 'Basic Information' group via the Modal Fields settings, the field silently disappears. The cause was a hardcoded skip in
renderTaskModalFieldGroups:The skip was originally added to avoid double-rendering the built-in basic fields (title, details), which have dedicated creation paths in
TaskModal(createTitleInput,detailsMarkdownEditor). Unfortunately, the same skip also discarded any user field the user moved into the basic group.This change:
renderTaskModalFielddispatcher to silently drop core basic fields (they are not infieldRenderers, and they are not user fields, sorenderTaskModalFieldreturnsfalseand they get counted inignoredFieldIds). Their UI surfaces remain unchanged because the dedicated creation paths still run elsewhere.renderUserFieldexactly like they do in every other group.task-modal__field-groupcontainer when the group produced zero rendered fields. This keeps the DOM clean for the basic group when it contains only core fields, and is also defensive against any future group whose fields are all core-only.Tests
Updates
tests/unit/modals/taskModalFieldRenderer.test.tsto reflect the new (correct) behavior — the previous expectations encoded the bug. Both tests now correctly reporttitle/detailsas ignored, and assert that empty group containers are removed.Adds
tests/unit/issues/issue-2045-user-fields-in-basic-group.test.tswith three cases:renderUserFieldAll new + updated tests pass. Full
tests/unit/modalssuite (37 suites, 187 tests) passes.tsc --noEmit --skipLibCheckclean.npm run lintclean.Verification
Note
This PR is separate from PR #2051 (issue #2046 NLP input autofocus). They were developed in parallel as independent fixes.