Skip to content

fix(ui): allow submitting the New project dialog without a name - #6073

Open
Master-Frank wants to merge 1 commit into
apache:mainfrom
Master-Frank:fix/6047-optional-project-name
Open

Master-Frank wants to merge 1 commit into
apache:mainfrom
Master-Frank:fix/6047-optional-project-name

Conversation

@Master-Frank

@Master-Frank Master-Frank commented Oct 11, 2026 •

Copy link
Copy Markdown
Contributor

Summary

The New project dialog required a name before its submit button became usable, so a user who only wanted a folder-named project had to invent a title before the folder picker would open. The catalog already falls back to the folder's basename when no name is given, so the dialog now treats the field as an optional override: submit is always available, an empty field submits as "no name", and the en/zh-CN/zh-TW copy says so instead of implying the name comes first.

  • NewProjectDialog: onSubmit(name?: string); empty/whitespace input submits undefined; submit button no longer disabled while empty.
  • WorkspacePickerGroup.onAdd?(name?: string) and its callers (task-entry controller, session-workspace recovery, Settings projects page) propagate the optional name; Settings passes undefined to window.maka.projects.add when blank so the service-side basename fallback applies.
  • Dialog tests cover the empty-name and trimmed-name cases; a Settings test asserts a blank-name submit reaches add with undefined.

Fixes #6047

Verification

  • npm --workspace @maka/ui run build && npm --workspace @maka/ui run test:dist — 735/735 pass (includes the updated new-project-dialog suite)
  • npm --workspace @maka/desktop run build:test — success
  • node --test on project-add-restore, task-entry-controller, task-entry-provider-scope — 80/80 pass
  • biome lint on all changed files — clean
  • Not run: full root npm test workspace-parallel suite (the affected suites above are the ones covering this change)

AI use

Select exactly one:

  • No generative tool made a substantive contribution
  • Generative tooling made a substantive contribution

Checklist

  • Tests cover the change and fail without it
  • Lint, format, typecheck and the affected suites pass locally

Does this PR entail a change in behavior?

  • Yes — described under Summary above
  • No

Generated-by: OpenCode (opencode/mimo-v2.6-pro)

@github-actions github-actions Bot added the effort/M Under 500 readable lines label Oct 11, 2026
@Astro-Han

Copy link
Copy Markdown
Contributor

Thanks for re-creating this. Before we review it: the AI-use section says generative tooling made a substantive contribution, but doesn't say which tool, and the commit has no Generated-by: trailer. Given #6059/#6060, could you name the tool used for this version (in the PR description, and ideally as a Generated-by: trailer)? As noted there, the project currently cannot accept Grok-generated changes; any other tool is fine. We'll review as soon as that's in place.

Automated notice: This comment was posted by an automated agent operated by Astro-Han, at the maintainer's direction.

@Master-Frank

Copy link
Copy Markdown
Contributor Author

Thanks for re-creating this. Before we review it: the AI-use section says generative tooling made a substantive contribution, but doesn't say which tool, and the commit has no Generated-by: trailer. Given #6059/#6060, could you name the tool used for this version (in the PR description, and ideally as a Generated-by: trailer)? As noted there, the project currently cannot accept Grok-generated changes; any other tool is fine. We'll review as soon as that's in place.

Automated notice: This comment was posted by an automated agent operated by Astro-Han, at the maintainer's direction.

done

@Astro-Han Astro-Han left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Automated review notice: This comment was posted by an automated review agent. It is not an independent human review and does not replace one.

I found no P0–P2 issue at 3d598c8eadeca716b5b3aaea5c80261e19f327e3.

The change removes the dialog's empty-name submission gate, trims an entered name, and passes undefined when blank. I traced that optional value through the workspace picker, Task Entry header, session-workspace recovery and Settings callers. The local management service already skips renaming when no name is supplied; the directory-backed catalog supplies its existing default name. Remote directory handoff retains its existing no-override behavior. The en/zh-CN/zh-TW labels and descriptions consistently identify the name as optional, matching the behavior proposed in #6047 without changing the directory-backed project model.

After a fresh dependency install and the normal root test build, all 735 UI tests, all 90 tests across the affected Desktop controller/provider/registration and project-service files, and all four Desktop typechecks passed. All ten changed files pass Biome. A mounted-dialog probe connected the actual component to the real management service and persisted catalog: blank, whitespace-only and trimmed custom names worked in all three locales; cancelling the directory callback created no project. Restoring the old non-empty-name guard makes the blank-name regression fail; restoring this head passes all three dialog tests.

P3 — commit attribution: the PR body declares substantive OpenCode use, but commit 3d598c8e has no Generated-by: trailer. Please add the declared tool to the commit message and retain the attribution through squash.

The exact head's CI is successful and it merges cleanly with checked main 6b9457f5. No protocol, epoch or database schema changed. I did not run the full monorepo test suite or a native Electron folder picker; the composed probe uses a controlled directory callback. This comment is not a merge approval.

The New project dialog required a name before its submit button became
usable, so a user who only wanted a folder-named project had to invent
a title before the picker would even open. The catalog already falls
back to the folder's basename when no name is given, so the dialog can
simply treat the field as an optional override: submit is always
available, an empty field submits as "no name", and the en/zh-CN/zh-TW
copy now says so instead of implying the name comes first.

Fixes apache#6047

Generated-by: OpenCode
@Master-Frank
Master-Frank force-pushed the fix/6047-optional-project-name branch from 3d598c8 to 8d9be01 Compare October 12, 2026 01:43
@Master-Frank

Copy link
Copy Markdown
Contributor Author

Automated review notice: This comment was posted by an automated review agent. It is not an independent human review and does not replace one.

I found no P0–P2 issue at 3d598c8eadeca716b5b3aaea5c80261e19f327e3.

The change removes the dialog's empty-name submission gate, trims an entered name, and passes undefined when blank. I traced that optional value through the workspace picker, Task Entry header, session-workspace recovery and Settings callers. The local management service already skips renaming when no name is supplied; the directory-backed catalog supplies its existing default name. Remote directory handoff retains its existing no-override behavior. The en/zh-CN/zh-TW labels and descriptions consistently identify the name as optional, matching the behavior proposed in #6047 without changing the directory-backed project model.

After a fresh dependency install and the normal root test build, all 735 UI tests, all 90 tests across the affected Desktop controller/provider/registration and project-service files, and all four Desktop typechecks passed. All ten changed files pass Biome. A mounted-dialog probe connected the actual component to the real management service and persisted catalog: blank, whitespace-only and trimmed custom names worked in all three locales; cancelling the directory callback created no project. Restoring the old non-empty-name guard makes the blank-name regression fail; restoring this head passes all three dialog tests.

P3 — commit attribution: the PR body declares substantive OpenCode use, but commit 3d598c8e has no Generated-by: trailer. Please add the declared tool to the commit message and retain the attribution through squash.

The exact head's CI is successful and it merges cleanly with checked main 6b9457f5. No protocol, epoch or database schema changed. I did not run the full monorepo test suite or a native Electron folder picker; the composed probe uses a controlled directory callback. This comment is not a merge approval.

Thanks for the review. Added the Generated-by: OpenCode trailer to the commit and force-pushed (8d9be01e), so the attribution will be retained through squash.

@Astro-Han Astro-Han left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Automated review notice: This comment was posted by an automated review agent. It is not an independent human review and does not replace one.

The previous P3 attribution issue is fixed at 8d9be01ef65c0a4dc19cae3de56556ea4111e5ea: the rewritten commit now includes Generated-by: OpenCode, and the PR body still identifies OpenCode and its model.

I compared this head with the reviewed 3d598c8e. Both commits have the same parent and the identical complete tree f08cc2c5e12e0d6e34f4ff315b114406335a3d15; the range comparison shows only the added commit trailer. There are no production, test, dependency, or generated-artifact changes to reassess.

The optional-name behavior and the previous functional conclusion therefore remain unchanged: empty/whitespace input reaches the folder selection without a custom name; the existing catalog fallback supplies the folder name; explicit names are trimmed; the three locales describe the optional field. The prior checks included the actual dialog/service/catalog flow and affected UI/Desktop tests. I did not rerun those tests for this metadata-only update.

CI run 38193023364 passed on this exact head. A trial merge with current main 105302c6 is conflict-free. This update adds no schema/protocol change and leaves epoch 217 unchanged. I found no new P0–P2 issue or remaining attribution blocker. Native folder selection was not independently exercised.

This branch has not been deployed

No deployments
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

effort/M Under 500 readable lines

Projects

None yet

Development

Successfully merging this pull request may close these issues.

New project requires a name before the folder can be chosen

2 participants