Skip to content
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

Merged
merged 175 commits into from
May 4, 2022

Conversation

nickoferrall
Copy link
Contributor

@nickoferrall nickoferrall commented Apr 13, 2022

Fixes #6322 & fixes #6287

This PR adds:

  • a GitLab label to the Estimate phase
  • the user can select "As Comment" or "Do not update"
  • if they select "As Comment", voting on a GitLab issue in Parabol adds a comment to the GitLab issue
  • the GitLab comment includes the "Powered by Parabol" link

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

nickoferrall and others added 30 commits February 21, 2022 17:14
…rabolInc/parabol into feat/6088/gitlab-issues-functionality
Base automatically changed from feat/6303/track-gitlab to master April 20, 2022 12:30
Copy link
Member

@mattkrick mattkrick left a 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, {
Copy link
Member

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

Copy link
Contributor Author

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 {
Copy link
Member

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

Copy link
Contributor Author

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!

@nickoferrall nickoferrall requested a review from mattkrick April 22, 2022 10:15
"dimensionName" VARCHAR(120) NOT NULL,
"gid" VARCHAR(140) NOT NULL,
"labelTemplate" VARCHAR(100) NOT NULL,
PRIMARY KEY ("teamId", "dimensionName", "gid")
Copy link
Contributor

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.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Copy link
Member

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

Copy link
Contributor

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.

Copy link
Contributor

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,
Copy link
Contributor

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.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

For the [Integration]DimensionFieldMaps, 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.

Copy link
Contributor

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.

Copy link
Contributor Author

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?

Copy link
Contributor

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.

Copy link
Contributor Author

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})
Copy link
Contributor Author

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

const gitlabAuth = await dataLoader
.get('teamMemberIntegrationAuths')
.load({service: 'gitlab', teamId, userId: viewerId})
if (!gitlabAuth?.accessToken) return null
Copy link
Contributor

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.

@nickoferrall nickoferrall requested a review from Dschoordsch May 3, 2022 14:24
@Dschoordsch
Copy link
Contributor

Since Matt had no -2 you are free to merge per our policy

@nickoferrall nickoferrall merged commit 54c309e into master May 4, 2022
@nickoferrall nickoferrall deleted the feat/6322/can-vote-on-gitlab-issue branch May 4, 2022 08:26
@github-actions github-actions bot mentioned this pull request Sep 26, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
4 participants