Creating JIRA Issues from the JIRA Macro Edit Modal

Hi all,
I’m currently working on adding an Issue creation feature for the JIRA Macro.
See: JIRA-78: Add support for creating issue from the JIRA Macro Edit Modal

@vmassol, Since you are the project lead for the JIRA Integration, I should ask you some questions about the design of the feature and how we should proceed.

Some context to begin with

Attlassian’s Confluence’s JIRA Integration provides the ability to create a new issue while inserting a Jira Macro.

I’d like to integrate a similar feature to XWiki’s JIRA Integration.

The way I thought this could be implemented is by providing a custom displayer for the JIRA Macro’s content which is a JIRA Issues list.

I’m currently keeping the work in progress in the following PR on the JIRA Contrib repo

Here are a few screenshots of what it currently looks like.

JRJC API

In order to create an issue, the user needs to first pick an instance on which the issue should be created.
Only once this is done, can they search for a project for which they want to create an issue.
After picking a project, they can see the issue types configured for the given project.
And only then, can we get the list of fields the user needs to fill to create an issue from the JIRA API.

For my first attempt, I decided to write a simple velocity service as an intermediary between the UI and the JIRA API.
We need to perform the JIRA API requests on the server side because we can’t give the credentials to the user’s browser.
I thought I would use the existing JIRA script service which allows to recover a JiraRestClient and implements a client for the JIRA API.

Now this is not completely needed for the issue creation use-case, I suppose we could just proxy the API requests and parse the JIRA’s API answer directly in the UI.
Instead I thought I’d reuse the existing set-up for accessing the API from a script service.
This means that the answer from JIRA is parsed by the API client server-side, and I then need to serialize it again to send it to the UI.
In the process, I believe in the first parsing implemented by the JIRA Rest client library, we lose some of the data.
In the project list metadata, I don’t have access to the project avatar. This is not a big deal but I do think it’s not optimal.
More problematic, in the issue creation metadata (The list of fields expected to create an issue), I’m missing the id of the field that I need to reference in the issue creation request. But I do find it when calling the JIRA API directly.

I tried upgrading the REST Client to version 6.0.1, in case it was a known bug that was fixed by atlassian.
This did not fix my issues.

WDYT? Should I try to fix or workaround those limitations?

Architecture

Facing these issues, I’d like to ask for your opinion on the approach we should take.

So far the architecture I went with was in:

• jira-macro-default:
  • Add a js/jira-pickers.js providing
    • Instance suggests
    • Project suggests
    • Issue type suggests
    • Suggests for JIRA fields with a set of valid options
    • Suggests for JIRA fields with an autocomplete
    • The issue creation form
    • Event listeners to inject the issue creation form and the instance suggest in the JIRA Macro edit modal.
  • Add a JIRAIssuesList type in org.xwiki.contrib.jira.macro.
  • Set the content descriptor of the JIRAMacro to use the JIRAIssuesList as display type.
  • Add a templates/html_displayer/jiraserver to require our jira-pickers JSX and to insert the suggest instead of a textarea.
  • Optionally add a templates/html_displayer/jiraisssueslist to require our jira-pickers JSX and insert our issue creation form, although this can’t do anything until we fix XWIKI-23059: Can’t set a custom displayer for macro content in CKEditor’s macro editor.
  • Add a dependency to org.xwiki.contrib.jira:jira-api and org.xwiki.contrib.jira:jira-macro-ui in the pom.xml.
• jira-macro-common:
  • Change the Display Type of the id parameter to JIRAServer.class
• jira-macro-ui (New):
  • Add a velocity script service to:
    • Retrieve the list of configured JIRA instances
    • Retrieve the list of projects for an instance
    • Retrieve the list of issue types for an instance and a project
    • Retrieve the list of expected fields for an instance, a project and an issue type.
    • Retrieve the list of suggested values for a field given an instance, a project, an issue type and the field to suggest for.
    • Create a new issue given a list of fields with their values.

I now think that we shouldn’t use the rest client present in org.xwiki.contrib.jira:jira-api because we can’t really fix the upstream issues. Instead, we should perform the API calls ourselves.

The thing is, I only need a very small subset of the whole JIRA API for the issue creation feature.

Do you think the velocity service approach is viable?

Should I introduce JIRA REST endpoints for the UI to use?

These endpoints are not meant to be a public API, I just need suggests for the issue creation form basically.

@vmassol, As the project lead, what structure or approach would you approve of?

Thanks,
Dorian.

1 post - 1 participant

Read full topic