mattermost-plugin-gitlab
mattermost-plugin-gitlab copied to clipboard
[GH-61]: Adding "Create Issue" and "Attach Comment to Issue" modals
Summary
Added a modal to create a GitLab issue on an existing project of the user.
- Created API to get all user projects, project labels, project assignees, project milestones, GitLab issues, and create an issue.
- Created a "CreateIssueModal" component to create an issue on GitLab and an "AttachCommentToIssueModal" component to attach comment to an existing issue on Gitlab.
- Created a "CreateIssuePostMenuAction" and "AttachCommentToIssuePostMenuAction" component and registered it as "PostDropdownMenuComponent" to open the create issue modal and attach comment to issue modal.
- Configured babel-loader to load .tsx and .ts files.
- Upgraded the dependencies in package.json to match the dependencies in the GitHub plugin.
Screenshots
-
Click "Create Gitlab Issue" or "Attach to Gitlab issue" in the context menu (shown when a user connects their GitLab account with the plugin installed) on non-system messages

-
Create Gilab issue modal will open

-
Search and select a Project and title of the issue

-
Select labels, assignees, milestone, and description if any, and click submit to create an issue

-
Attach comment to issue modal

Ticket
Fixes #61 (Adding create issue modal and Attach comment to issue modal)
Hello @raghavaggarwal2308,
Thanks for your pull request! A Core Committer will review your pull request soon. For code contributions, you can learn more about the review process here.
Codecov Report
Attention: Patch coverage is 2.57353% with 265 lines in your changes are missing coverage. Please review.
Project coverage is 32.02%. Comparing base (
191a11a) to head (e0e2765).
:exclamation: Current head e0e2765 differs from pull request most recent head fe33b33. Consider uploading reports for the commit fe33b33 to get more accurate results
| Files | Patch % | Lines |
|---|---|---|
| server/api.go | 3.12% | 217 Missing :warning: |
| server/command.go | 0.00% | 25 Missing :warning: |
| server/plugin.go | 0.00% | 23 Missing :warning: |
Additional details and impacted files
@@ Coverage Diff @@
## master #306 +/- ##
==========================================
- Coverage 34.02% 32.02% -2.00%
==========================================
Files 22 22
Lines 4021 4293 +272
==========================================
+ Hits 1368 1375 +7
- Misses 2515 2780 +265
Partials 138 138
:umbrella: View full report in Codecov by Sentry.
:loudspeaker: Have feedback on the report? Share it here.
This PR has been automatically labelled "stale" because it hasn't had recent activity. A core team member will check in on the status of the PR to help with questions. Thank you for your contribution!
@mickmister Gentle reminder for review
@mickmister Gentle reminder for review
@mickmister Gentle reminder for review
This PR has been automatically labelled "stale" because it hasn't had recent activity. A core team member will check in on the status of the PR to help with questions. Thank you for your contribution!
@spirosoik FIxed the review fixes you mentioned
@mickmister Gentle reminder for review
@mickmister Gentle reminder for review
@mickmister Gentle reminder for review
@mickmister Fixed the review comments you mentioned
This PR has been automatically labelled "stale" because it hasn't had recent activity. A core team member will check in on the status of the PR to help with questions. Thank you for your contribution!
Hi @raghavaggarwal2308, I've done a round of testing on this and it's looking pretty good! 👍 I have a bit more work to do but, I wanted to raise some points with you:
- It looks like the create option always has the selected version of the light theme applied even when the option does not have focus and a different theme is applied.

- The Issue Title box accepts 1 too many characters so it can exceed the GitLab max. This is an edge case but, can we set the field to have a max 1 character shorter so that it is impossible to try creating an issue with a title too long for the GitLab side?

- Also the error is cryptic ☝️ . If there are similar ones - I wonder if you could trim the special characters out
{}[] - The business logic for which issues/projects you can select for for attach is a bit odd. I am aware that this is also the case for GitHub plugin but, I'm not sure we should copy it. Create has business logic to show only the users projects.(I'm not sure exactly what it is) But Attach will allow the active user to search for and select any project where issues are configured that any GitLab user can add a comment.


Can we consider just allowing attach to work with the same projects as create rather than matching the GitHub logic here? cc @asatkinson who may also have thoughts on this point.
This PR has been automatically labelled "stale" because it hasn't had recent activity. A core team member will check in on the status of the PR to help with questions. Thank you for your contribution!
@mickmister Fixed the review comments you mentioned
@DHaussermann Working on the comments you mentioned.
@DHaussermann Should we make the changes suggested in point 4 or should we wait for the reply of @asatkinson.
@DHaussermann Just a suggestion for point 4, we can also use the config setting "Gitlab Group". When the setting is empty we can show all issues and when it is specified we can display the issues related to that group only.

@DHaussermann Should we make the changes suggested in point 4 or should we wait for the reply of @asatkinson. @DHaussermann Any updates on this?
@raghavaggarwal2308 yes your suggestion above is an option. This is how GitHub works. I just find it very awkward to use when there is no Org lock in place so, I would consider that we do not need to match that business logic.
What is the business logic for the repos in the create issue drop down?
@DHaussermann In create issue drop down we get all the projects of the connected user.
@DHaussermann In create issue drop down we get all the projects of the connected user.
hmmm... I see. Yes this does not feel appropriate here for attach. Maybe the best thing to do is keep as is AND make sure it also works like GitHub in that if there is an Org lock in place it filters the repos.
@asatkinson do you have any objections to this? We already go it for GitHub it just looks very sloppy when Org lock is off.
@DHaussermann Made the changes suggested by you
@DHaussermann This is ready for review
This PR has been automatically labelled "stale" because it hasn't had recent activity. A core team member will check in on the status of the PR to help with questions. Thank you for your contribution!
@DHaussermann Gentle reminder for re-review
@DHaussermann Gentle reminder for re-review
@DHaussermann Gentle reminder for re-review
@DHaussermann Gentle reminder for re-review
@DHaussermann Gentle reminder for re-review