Git Integration for Jira (GIJ) Feedback

Currently out application does not support project key changes in Jira Cloud. If a Jira project key is changed, our application will not keep the git items that were previously linked using the old Jira issue key. It would be helpful if we could implement support for keeping historical git data links after project key changes.

Currently, while we continue to display pre-key change commits/branches/PR's inside Jira issues after a Project key change, the API will only report data that is associated with the new Key. It would be helpful for clients to be able to still get the pre-key change data included in the API results.

Associate the Pull Request Reviewer if exists in Jira. Originally posted for GitHub.

We have a repo in Bitbucket connected. I have noticed, that in the tickets and the development window some information is mission for the "Git integration for Jira" part. The Image of the author is seen in the bitbucket integration, but not in the Git Integration for Jira, also the Reviewer is mission and only available in the Bitbucket integration. So please add this information, since its available in the system and quite usefull. Especially the reviewer information is needed in Jira to just works on a base level in jira and to not need to switch all the time back and forth.

Allow users to enable the create branch option per integration, as currently this is a global setting and affects all projects.

GIJ DC currently offers the 'Enforce Git Service Permissions' setting, which helps clients restrict data visibility to only the things that their user account has access to. This would be a great addition to GIJ Cloud in order to have more security options available to users looking to restrict data visibility.

We have standardised branch naming guidelines, and one request from a stakeholder was having the ability to restrict the branch creation template such that you cannot create a branch without a jira Issue Key, since it currently allows a user to modify the template in any capacity that they like. This way, it would allow us to establish and enforce the standards.

Once a Issue is resolved, we would like the ability to disable the ability to create a new branch from said Jira Issue. This is to prevent branches being associated with issues that are considered "done" by the business

For users whose Jira is hosted behind a firewall/proxy, and they are unable to expose the internal URL, Github apps will get stuck in 'Installing' status due to the installation completion webhooks not reaching the intended internal (private) endpoint. As a work around, some clients have been able to successfully setup external facing proxy URL's to capture the webhooks and forward them to the correct internal endpoint to complete the installation. In this workflow, the webhook URL from the Github App must be retrieved on the GH side of things after the app has been authenticated, then the proxy is configured to redirect to this (original) internal endpoint. Once that is done, the GH app webhook must be modified to point to the proxy URL, and then the webhooks must be resent to complete the installation. For clients like these, it would be extremely helpful to have an advanced settings field that would allow them to specify a different proxy URL domain, which will be passed in the GH App manifest instead of the internal domain. This way, the clients will not have to manually go and grab the webhook URL and then point the proxy to the original URL. The Proxy can be setup to route the external domain URLs to the internal domain endpoints. In the proposed workflow, the GH app will be created with the proxy URL, and the webhooks should be delivered to the to the internal address without any manual modifications to anything.

Currently, the plugin only supports Classic Release pipelines. While these are great for most use cases, some customers do use the power of yaml pipelines were they can define multiple stages and steps.