-
Notifications
You must be signed in to change notification settings - Fork 336
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
feat(sprint-poker): Can vote on GitLab issue #6398
Conversation
…rabolInc/parabol into feat/6088/gitlab-issues-functionality
packages/server/graphql/mutations/helpers/pushEstimateToGitLab.ts
Outdated
Show resolved
Hide resolved
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
looking good! My only advice would be to consider filling up the GitLabServerManager with all the helper functions you can to set a good pattern moving forward
meetingName, | ||
discussionURL | ||
) | ||
const [, commentError] = await gitlabRequest(createNote, { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
+1 I know we pushed it off on the last PR. Is this PR the right time to have GitLabServerManager implement TaskIntegrationManager? Having another integration using that abstraction could do some good in how they shape up & remove the need for a large refactoring PR at the end of this milestone
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I've implemented the new pattern including createNote
in this PR: #6427
import {GQLContext} from '../graphql' | ||
import UpdateGitLabDimensionFieldPayload from '../types/UpdateGitLabDimensionFieldPayload' | ||
|
||
interface Args { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
-1 could you write this as a resolver using the new SDL pattern? that way these args will be provided for you
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Nice, it was cool to see the new pattern! The type safety is so good 🙌 Update pushed!
packages/server/postgres/migrations/1649750150687_GitLabDimensionFieldMap.ts
Outdated
Show resolved
Hide resolved
"dimensionName" VARCHAR(120) NOT NULL, | ||
"gid" VARCHAR(140) NOT NULL, | ||
"labelTemplate" VARCHAR(100) NOT NULL, | ||
PRIMARY KEY ("teamId", "dimensionName", "gid") |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
-1 Why have an id
field if it's not the primary key? It does not even have a unique constraint.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I followed the GitHub example here: https://github.com/ParabolInc/parabol/blob/cf55ed4d0877b1756ffc7213062dde5056ed662b/packages/server/postgres/migrations/1631822263196_GitHubDimensionFieldMap.ts
I'm not sure why. Perhaps @mattkrick could help clarify?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
every node needs an ID in graphql/relay so i just gave it a one so we didn't have to concat 3 fields together ("teamId", "dimensionName", "nameWithOwner")
. safe to remove if you'd rather concat em
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm also fine with keeping it, but it must have a unique
constraint since you can just insert/update serial fields.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm also fine with keeping it, but it must have a unique
constraint since you can just insert/update serial fields.
"id" SERIAL, | ||
"teamId" VARCHAR(100) NOT NULL, | ||
"dimensionName" VARCHAR(120) NOT NULL, | ||
"gid" VARCHAR(140) NOT NULL, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
-2 I don't understand why we store the voting dimension by issue id. I think we should have the providerId
, projectId
instead, so it is set for the project and all upcoming voting issues.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
For the [Integration]DimensionFieldMap
s, my understanding is we want to store the dimensionName
, e.g. Story Points, and labelTemplate
, e.g. __comment
, associated with a particular project/repo.
We do this so that the user's preferences are stored so they don't need to keep changing between "As a comment" and "Do not update", for example.
Previously, I thought it was associated with an issue, so I was storing the gid
. But, I now see that when I update the "As a comment" label to "As a label", in the GitHub integration, it updates the label for all other issues in that repo.
So, I agree that I should change gid
to projectId
so that we store the preferences for all issues within a project in GitLab.
What I'm unclear on is why we should have providerId
? Are you thinking we should have this instead of teamId
? The same issue could exist in multiple teams. By including the teamId
, we only update the label preference on that team.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I would like to tie all integration settings to their provider. As these are potentially self-hosted a client could switch between two instances where both use the same ids belonging to different projects. Or teams move orgs, there are some scenarios where this could happen. We should keep the teamId
as well.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Storing the providerId makes sense for that self-hosted switching edge case. So you're happy for us to store teamId, projectId, dimensionName, and providerId here?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
As the key/unique constraint to lookup the setting, yes. And then "labelTemplate" to store the actual setting.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Sounds good. Update pushed!
const manager = new GitLabServerManager(accessToken!, provider.serverBaseUrl!) | ||
const gitlabRequest = manager.getGitLabRequest(info, context) | ||
|
||
const [data] = await gitlabRequest<GetIssueQuery>(getIssue, {gid}) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
In this PR #6427 this is refactored to use the TaskIntegrationManager
pattern
packages/server/graphql/mutations/helpers/pushEstimateToGitLab.ts
Outdated
Show resolved
Hide resolved
packages/server/graphql/public/typeDefs/updateGitLabDimensionField.graphql
Show resolved
Hide resolved
const gitlabAuth = await dataLoader | ||
.get('teamMemberIntegrationAuths') | ||
.load({service: 'gitlab', teamId, userId: viewerId}) | ||
if (!gitlabAuth?.accessToken) return null |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
-2 This is failing for meeting participants without gitlab integration. They will not be able to join a Poker Meeting with GitLab issues at all.
GraphQLError: Cannot return null for non-nullable field EstimateStage.(serviceField,serviceField,serviceField,serviceField,serviceField,serviceField,serviceField,serviceField).
Reproduce: Ingo has GitLab integration, creates a Poker Meeting, adds GitLab tasks and moves to estimate stage. Paul has no integration and tries to join the meeting.
Since Matt had no -2 you are free to merge per our policy |
Fixes #6322 & fixes #6287
This PR adds:
Note: when selecting the "As Comment" or "Do not update" label, the Update/Edit Score button can flicker. This bug exists in GitHub in prod, so I created an issue for it: #6397