Michael Uray
0e6d0dfc7f
Schema-only foundation for the upcoming Gantt-chart view in tracker.
No UI in this PR.
Changes:
- Issue.startDate: Timestamp | null (interface + IssueDraft + @Prop with @Index)
- Milestone.startDate: Timestamp | null (interface + @Prop, reusing the
existing tracker.string.StartDate IntlString)
- New DependencyKind type ('finish-to-start' | 'start-to-start' |
'finish-to-finish' | 'start-to-finish')
- New IssueRelation AttachedDoc class with kind: DependencyKind, signed
lag: number — registered in models/tracker via TIssueRelation
- 7 new IntlString keys: IssueStartDate, GanttDependency,
GanttDependency{FinishToStart,StartToStart,FinishToFinish,StartToFinish},
GanttLag — all 13 locales updated
- Cross-plugin literal updates in importer + github sync to satisfy the new
required Issue.startDate / Milestone.startDate fields:
- packages/importer/src/importer/importer.ts: AttachedData<Issue> literal
- services/github/pod-github/src/sync/issueBase.ts: 'startDate' added to
GithubIssueData Omit list (github sync does not own scheduling)
- services/github/pod-github/src/sync/issues.ts + pullrequests.ts:
AttachedData<Issue|GithubPullRequest> literals
Out of scope (deferred to follow-up PRs):
- UI for Gantt view, drag/resize, dependency editor, critical path
- blockedBy → IssueRelation migration (ships atomically with the writer
redirect in the dependency-UI PR)
- LinkIssues permission (tracker uses forbid-style permissions; needs
maintainer discussion)
- Activity-feed wiring for IssueRelation (needs a producer to test against)
- IssueTemplate.startDate (template propagation semantics undecided)
Signed-off-by: Michael Uray <michaeluray@users.noreply.github.com>
Tasks for Github integration
Project management from Huly (Postponed)
-
Observe all existing/closed projects and retrieve all custom field values and store them into Huly custom fields. It could be separate set of mixins possible.
-
On update of custom fields, propagate changes to appropriate project/field.
-
Status (Huly) is more rich in compare to issue/pull request (open/closed) status of Github. But for Projects, it could be "single_select" option to be used. But github right now doesn't provide a way to manage existing fields. So we could not maintain state of status field on github project. We only create/delete it. Possible workarounds:
- Map Huly Status to Project Status field, and ask user to perform manual definitions of required status values. We will map by status name if appropriate value will be found.
- On changes in Platform Status, we should show appropriate message about requirements to manage status on Github project.
- On changes on Github side we could add necessary status values into Huly synchronized projects.
-
A list of issue for ProjectsV2 graphql APIs missing on GitHub side. https://github.com/orgs/community/discussions/61457
-
Enum values could be mapped to Github single_select values, but they could be created only from Github platform to prevent API limitations.
-
Text/number fields could be created from both sides.