[GH-865]: Solved the bug: Jira issues cannot be created anymore with Jira Server/Datacenter 9.x

[Nityanand13]

Summary

The REST endpoint rest/api/2/issue/createmeta was removed in Jira Server 9, due to which we were not able to create an issue in Jira from mattermost.

Ticket Link

Issue #865

[mattermod]

Hello @Nityanand13,

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-commenter]

Codecov Report

Base: 31.27% // Head: 30.94% // Decreases project coverage by -0.32% :warning:

Coverage data is based on head (11fbdfe) compared to base (a6aa3fe). Patch coverage: 0.00% of modified lines in pull request are covered.

Additional details and impacted files

@@            Coverage Diff             @@
##           master     #881      +/-   ##
==========================================
- Coverage   31.27%   30.94%   -0.33%     
==========================================
  Files          49       49              
  Lines        6017     6081      +64     
==========================================
  Hits         1882     1882              
- Misses       3946     4010      +64     
  Partials      189      189              

Impacted Files	Coverage Δ
server/client.go	9.25% <ø> (ø)
server/client_cloud.go	0.00% <0.00%> (ø)
server/client_server.go	0.00% <0.00%> (ø)
server/command.go	17.05% <0.00%> (-0.15%)	:arrow_down:
server/issue.go	31.78% <0.00%> (ø)

Help us with your feedback. Take ten seconds to tell us how you rate us. Have a feature suggestion? Share it here.

:umbrella: View full report at Codecov.
:loudspeaker: Do you have feedback about the report comment? Let us know in this issue.

[javaguirre]

I think by making @mickmister proposed changes we're good to go 🚀

[javaguirre]

@Nityanand13 Is this finished? Please push the "request another review" button so we know we have to review again, thank you! :-)

You need to rebase, this branch has commits from master.

[mickmister]

You need to rebase, this branch has commits from master.

@javaguirre In general I try to discourage rebasing for open PRs, specifically because it results in a force-push, which messes up the review history of the PR. If there are other commits in the PR, the PR will be squashed into one commit that we want, as long as the diff is correct with what we're trying to introduce into master.

There are currently a bunch of unrelated changes though. I'm not sure why those are showing like that if we're pointing the PR to master.

[javaguirre]

You need to rebase, this branch has commits from master.

@javaguirre In general I try to discourage rebasing for open PRs, specifically because it results in a force-push, which messes up the review history of the PR. If there are other commits in the PR, the PR will be squashed into one commit that we want, as long as the diff is correct with what we're trying to introduce into master.

There are currently a bunch of unrelated changes though. I'm not sure why those are showing like that if we're pointing the PR to master.

If there are changes in master you might need to rebase in your branch, otherwise you are not building/testing with the latest changes and you might not be doing the "right" thing (there might be commits in master that affect what you're doing in your PR).

IMHO your branch review history is your realm until you merge into a stable branch, so you could change it at will as long as the commits and changes are organized.

[Nityanand13]

You need to rebase, this branch has commits from master.

@javaguirre In general I try to discourage rebasing for open PRs, specifically because it results in a force-push, which messes up the review history of the PR. If there are other commits in the PR, the PR will be squashed into one commit that we want, as long as the diff is correct with what we're trying to introduce into master. There are currently a bunch of unrelated changes though. I'm not sure why those are showing like that if we're pointing the PR to master.

If there are changes in master you might need to rebase in your branch, otherwise you are not building/testing with the latest changes and you might not be doing the "right" thing (there might be commits in master that affect what you're doing in your PR).

IMHO your branch review history is your realm until you merge into a stable branch, so you could change it at will as long as the commits and changes are organized.

Now there are not unrelated changes.

[mickmister]

If there are changes in master you might need to rebase in your branch, otherwise you are not building/testing with the latest changes and you might not be doing the "right" thing (there might be commits in master that affect what you're doing in your PR).

IMHO your branch review history is your realm until you merge into a stable branch, so you could change it at will as long as the commits and changes are organized.

@javaguirre I may be speaking too literally here, with the word "rebase". The PR should stay up-to-date with master, though I have the preference of "merging" master into the branch, rather than "rebasing", specifically because rebasing results in force-pushing. Sometimes rebasing makes more sense because of the nature of the changes, though typically just merging master into the branch and pushing without force-pushing is preferred, at least from the PR reviewer's side. I prefer it as a developer as well in almost all cases.

Things that GitHub provides such as the "Outdated" label on review comments, and the "Changed since last view" label when reviewing files, relies on the PR having a steady commit history, and it can't have any force-pushing. This makes past reviews much more meaningful and useful, especially on PRs that touch a lot of files. If force-pushing is done, I always re-read the whole PR, partially because of security implications. When there is a force-push, it's not possible to tell what has changed and what hasn't changed since the last review.

[mattermod]

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!

[mattermod]

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]

@DHaussermann This PR that fixes support for Jira 9 is now dev approved

[DHaussermann]

/update-branch

[mattermod]

We don't have permissions to update this PR, please contact the submitter to apply the update.

[mattermod]

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]

/update-branch

[mattermost-build]

We don't have permissions to update this PR, please contact the submitter to apply the update.

[DHaussermann]

@Nityanand13 and @mickmister this looks like it may solve the problem. But I see a crash occur when selecting now. To me - This looks like an issue with React Dom already patched in the production release.

Can one of you please pull master branch in so I can try again?

[DHaussermann]

Also cc @hanzei are you able to sort why I can't attempt a pull master up into this branch?

Edit: Oh I see it's not opened in the MM org

[DHaussermann]

@hanzei and @mickmister as this is a very high impact issue, we should consider creating a 3.2.3 dot release for this rather than getting the rest of 3.3.0 ready.

cc @asatkinson

[inwx-developer]

Any chance we will get a 3.2.3 release?

[hanzei]

Here you go: https://github.com/mattermost/mattermost-plugin-jira/releases/tag/v3.2.3