[MichaelUray]

Fixes #4858

Problem and change

The milestone selector used when creating or editing an issue only listed existing milestones, so a milestone that did not exist yet could not be added without leaving the issue dialog. NewMilestone also did not report the created milestone back to its caller.

The selector now offers a "New Milestone" entry when it is bound to a single project. It opens the existing NewMilestone dialog for that project and selects the created milestone afterwards (only if it was created in the same project, since the dialog allows changing the project). NewMilestone now passes the id of the created milestone when it closes.

Tests

No unit test (popup wiring). Checked manually on a self-hosted instance: in the New issue dialog the milestone selector lists "New Milestone" after "No milestone"; it opens the milestone dialog for the current project and the created milestone is selected; the same works on an existing issue's milestone field; the bulk context-menu action does not offer it.

[ArtyomSavchenko]

@MichaelUray Please take a look at failed formatting:
https://github.com/hcengineering/platform/actions/runs/40339492324/job/123249403505?pr=11137

What do you think about this suggestion?
canCreate doesn’t check whether the user may create milestones in that project. Users without that right see the entry and then hit a server error on save. That matters more once #11149 (Forbid create object) lands; gating on canCreateObject(tracker.class.Milestone, space, …) would keep the menu honest.

[MichaelUray]

@ArtyomSavchenko Thanks for checking this. I investigated the latest CI run on 5a92263f; the formatting failure comes from mixed merge revisions.

The build checks out the moving PR merge ref, while formatting checks out the event’s original merge SHA. The build cache includes source files, so restoring it overlays newer develop changes onto the older checkout:

• build logs Merge 5a92263f… into f292d165… and Cache saved with key: Linux-build-cache-build-results-36cd99f2a52b891be8de252b18ccef14437eddff.
• formatting logs HEAD is now at 36cd99f2a5 Merge 5a92263f… into e3f4f168…, logs Cache restored from key: Linux-build-cache-build-results-36cd99f2a52b891be8de252b18ccef14437eddff, then exits 1 on five file diffs.
• I matched every diff hunk to develop e3f4f168…f292d165, from #11144, #11072, #11068: plugins/tracker-resources/src/components/NewIssueHeader.svelte, plugins/tracker-resources/src/components/issues/edit/ControlPanel.svelte, plugins/view-resources/src/actionImpl.ts, plugins/view-resources/src/components/ActionHandler.svelte, plugins/view-resources/src/components/ActionsPopup.svelte. None of these files is changed by this PR.

I’m preparing a separate workflow-fix PR to pin the checkouts to github.sha, make cache consumers restore-only, and rebuild on a cache miss. Re-running an old run keeps its original workflow definition and can repeat these failures.

I’ve addressed the milestone permission suggestion with canCreateObject(tracker.class.Milestone, space, …); I’ll push the follow-up commit with that change shortly.