Why_So_SeriousandGitHub
e34f546b8c
* fix(github): honour the force flag in checkRefreshToken `checkRefreshToken` accepts a `force` parameter but never reads it, so the only caller that passes `force = true` (worker.ts, when re-syncing a user) behaves exactly like the non-forced call and skips the refresh entirely. Gate the refresh on `force || expired` instead of on expiry alone. As a side effect a record with a `refreshToken` but a null `expiresIn` is now validated when forced, instead of being reported as valid unchecked. Signed-off-by: koreanjoker <namug014@gmail.com> * fix(github): return undefined from getOctokit when the token is dead When `checkRefreshToken` reports failure, `getOctokit` cleared `record.octokit` and then fell straight through to constructing a new Octokit from the very token that was just rejected. The method therefore never returned `undefined` for a revoked user, so the `(await getOctokit(...)) ?? container.container.octokit` installation-token fallback that the sync code already writes at 13 call sites was unreachable. Return `undefined` after clearing the client so the existing fallback can take effect. Signed-off-by: koreanjoker <namug014@gmail.com> * fix(github): preserve accounts when deserialising a user secret `updateUser` serialises the whole `GithubUserRecord` — `accounts` included — into the integration secret, but `secretToUserRecord` placed a literal `accounts: {}` after the spread of the parsed payload, discarding whatever was stored. Every consumer of a record loaded through `getAccount` therefore saw an empty map. `revokeUserAuth` iterates `Object.entries(record.accounts)`, so its body never ran and the re-authorisation notice was never written to any workspace. Read `accounts` back from the parsed payload, keeping `{}` as the fallback for records written before the field existed. Signed-off-by: koreanjoker <namug014@gmail.com> --------- Signed-off-by: koreanjoker <namug014@gmail.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.