ok sry. thought that would be a part of it

Steven & Mark Oliver, the "solution" you provided has nothing to do with the issue. It's about automagically generating Jira issues from a Confluence table, not generating a Jira issue by inserting the Jira Issue macro.

While in reading mode of a Confluence page, you can mark some content in a table. After a second, a small popup allows you to create an inline comment OR (if connected to a Jira instance) create a Jira issue from the marked text. When you do this inside a table, Confluence asks to create an issue for every table row.

Thank you. I will make the update this evening and report back tomorrow

They are required via Field Configuration, not a workflow validator. That would be a likely difference to consider. I am using Confluence 6.6.3 and Jira 7.7.1.

ah ok. Thanks for the feedback. Which Confluence Version are u using?  In 6.5 i don`t get the additional required fields... or did you do somehting else but setting the fields in the field configuration in Jira as required?

regards Mark

Required fields should show up just fine.

it would be great to create issues from confluence with assignes, epic link and the due date ... right now we are switching to Jira to finish the job ... not that straigt. 

i don´t believe there is a easy way to configure the fields that are shown in the confluence pop up window. 

What a shame this isn't being considered despite such overwhelming demand. This feature would be such a performance aid for us.

Not impressed.

Thanks for your interest in this issue.

While this suggestion has gathered significant interest, we're unable to implement all of the excellent suggestions you make. We appreciate the benefits of such requests, but don't plan to work on this for the foreseeable future.

This suggestion will be reviewed in about 12 months time, at which point we’ll consider whether we need to alter its status.

@carson price - agree, especially with the anchor.  We have those large requirements pages in Confluence, which have multiple User Stories reference them.  Would be great if the User Story linked back to the relevant part of the page in Confluence without messing around.  We try to follow the model - info in Confluence, and tracking in JIRA, so there is only one place to update.  With varying degrees of success! 

I'm hoping to roll this out to our entire organization to start doing. We have 3 fields that we wish would map correctly. Title, description/Acceptance criteria, and User story. If my developers didn't have to leave Jira when working it would be great. Also it would be awesome if these links were anchors, I don't want them just to be taken to the page but to be taken to the part of the page that this story was created from. 

I would say, at a minimum, in addition to the Summary and the Epic Link, I want Description and Verification Criteria (User Acceptance Criteria).  That way, I can define all these in Confluence then make the Issue in Jira with them all filled in already.

Would be really good if there was 2 way update also - update it in JIRA, automatically is updated in Confluence and Vice Versa.

Right now, it's like you do all this good stuff in Confluence to start, but when development starts, Jira is a lot more immediate to use, so from that point on, I'm thinking of having a Jira macro in confluence listing all the stories with descriptions.

Is there any recent development on this? 

This so called "Integration" feature is null and void if you have required custom fields. 

This is not only with Confluence but also with with Crucible / Fisheye integration. It all is good until you try to create a JIRA from that application and you are restricted since there are required fields. 

This type of integration doesn't seem seamless to me. And the only workaround is to remove the required field validations, which is not the best ever.

What do you mean with "Details"? Summary and description are mapped actually.

We would need the Summary and the Details

+1 yes please 

it would be fantastic if you could map a table where the columns are the various issue fields and confluence would allow you to enter the info there for a complete issue and create it using the data in the table.

Would be a great idea to just implement custom fields in general into Confluence. 

If fields could be added to pages and templates, if they could be editable by user or not, and editable from the page itself and not only from "edit" page,

1/ it would be much easier for user to modify a page,

2/ it'd be wonderful for admins who don't want users to be able to modify the entire page but only parts of it,

3/ it could lead to confluence reports and make it easier to link JIRA and other connectors like Salesforce.

Basically it would make Confluence much more than a documentation tool

Hope this will happen!

Can we have any progress on this?. Mapping predefined fields like Description, Priority or Assignee maybe a better start than waiting without anything like it is today.

I agree that this is critical functionality,and also agree that the simple ability to use the confluence headings to  map to efields like Project, Assignee, DueDate... would be all that is needed for an initial release of this feature. 

we really need a way to add the assignee when creating tickets from within Confluence

Yes, please make some progress on this.

I also support the call for taking over the  formatting from Confluence

It's hard to believe that this issue has been open for three years and there's still no action from Atlassian. The current functionality is pretty much useless. Why not at least add the ability to fill the essential fields: Project, IssueType, Summary, Description, and Assignee?

This is a critical missing component for us. As a first pass, just having JIRA fields Project, Issue Type, Summary, Description, Priority, Assignee would do the trick. Assignee is critical - we should be able to @mention a user in the Confluence table row and the resulting Jira ticket will have that user assigned.

Having the ability to create these tables in Confluence Page Templates with defaults including variable-ized @mentioning users (imagine a set of boilerplate tasks that always needs to be done...) would also be huge. 

Acceptance Criteria would help us dramatically

Is this issue already in roadmap ? When can we expect to see this in live ?

Thanks!

The Chrome Extension is here !

There is a FREE version that let's you push formatting from Confluence to Jira tasks for Summary & Description.

There is a PAID Subscription based version that includes the ability to transfer attachments, assignments, reporter information, labels and any custom fields with a 'string' datatype for multiple columns. The Paid version if ever evolving adding new fields upon requested demand.

Reformatting data in both systems is a time-consuming task. Streamline your workflow between Confluence and Jira with Conjir.

It would indeed be very welcome if you could select more fields while creating issues from a table, besides summary and description. For example story points, due dates, etc.

My organization's view on this is that when one is creating a JIRA issue directly from a Confluence page, the prompt which displays in Confluence should match exactly the Create Screen for the issue type in question in JIRA. It makes no sense that our users would populate different fields whether they were creating the issue from Confluence or from JIRA, especially when these apps are used so closely together. By simply displaying the Create Screen as configured from JIRA, that consolidates the administrative burden of this to the JIRA configuration.

+1 for linking a column to a jira field. We need status, but also a number of custom fields.
+1 for round-trip to keep the linked Confluence Columns up to date with any changes in Jira and vice versa. I.e. an automatic update as well as an initial create.

We use Confluence for requirements, JIRA for development and testing. So this current feature, while good, would become far more useful if there was some way to be able to make changes in one system only, rather than having to keep them in sync manually. The more fields that are added, or if it is made generic, the more easily the data gets out of sync. The more out of sync the less useful it becomes over time.

We need to make jira issues from requirements. If it is complicated, make simple solution that current is.

We need: Summary, description, original estimate, assigne, reporter, epic, account. Also from page macro i could fill out jira issue (reporter, epic, account).

+1 for feature

Sam, I would also be interested in your extension .

Sam, I would also be very interested in your Google Chrome add-on.

Sam, I'd be interested in checking out the chrome extension. Would it be possible to obtain a copy?

I'd love this a templating system for repetitive work.

Bryon - i've sent you an email so you can test out the extension. anyone else interested? it just does formatting of your Description (Bold, Lists, Paragraphs) & Adds Image Attachments per issue.

It would make my life significantly easier.

Also based on the activity of this thread, I would say that there would be demand.

Negative. It's just a DEV version now. if there is high demand for it we will put it on the Chrome store & support it.

Sigh. The half finished feature that still isn't finished. Will it make 3 years? I imagine so. The occasional comments on this act as a constant reminder of this infuriating shortfall, and just how amazing the Confluence-JIRA integration COULD have been.

Can someone get this extension via the Chrome web store?

We have created a Chrome Extension that syncs your confluence page to Jira to update all text formatting & attaches images per issue. Pretty slick. Works well & is pretty rudimentary to start. Saves me TONS of time already.

We found that Jira & Confluence do not share the same rendering engine so no wonder Atlassian is NOT pushing this update because it's a pain to capture all use cases.

For what it's worth, I think the fact this simple enhancement has sat around for multiple years with no activity, speaks volumes to how Atlassian perceives it.

Markup matching from confluence to JIRA would make things significantly easier... I'm going to have dreams about SHIFT-8, space, down arrow, left arrow.

This would make our life so much easier. It sounds like creating a table that based on your screens schemes would maybe make the most sense.

We would like to be able to add work estimates and other custom fields.

This Story has been open since 2013 - i really don't think it will get worked on.

I have to agree w/ this guy

I would like the data formatting match what's in Confluence. The wiki-markup does not translate from one system to another.

Also, i would like my images to transfer over as well. So if we could include mapping to the attachments, that would be great.

This feature would make life a lot easier... doesn't seem all that hard either.

Both our Development team and QA team use this feature and even if all we could map in addition to Summary is Description, that would be a big win for us. As a user, I might expect you to match column to Description field on either the column immediately after the selected Summary column OR match based on the table's column header text ("Description" column header will be used for the resulting issue's Description field).

I really thought I saw this functionality in Jira 7.1 as recently as January 2016. Was I mistaken?

We would like to map quite a lot of the fields we use. We haven't turned on required fields as this prevents other tools such as Bamboo.

We use Story, Description and MoSCow Size. Would be great if you defined a "Field" in Jira for a certain issue type to be able to map it to a "Column" in Confluence.

I typically create a table in confluence with two columns, Story and Description. I have rich text in the description field, such as bulleted lists and links to other confluence pages. When I run the bulk create jira issues feature, all of the text markup gets stripped out from the newly created jira tickets. The lists are no longer bulleted and the hyperlinks are lost. For example, the confluence text looks like this:

• Item 1
• Item 2
• Item 3

And the bulk created Jira text looks like this:

Item 1Item 2Item 3

I changed the field renderer for the description field in Jira from plain text to "wiki markup" but that didn't work. It actually made things worse, because the wiki markup renderer only handles a few lines of text then ends the paragraph with....

It doesn't load the entire description field from confluence into Jira. The Plain text renderer doesn't have this issue.

It would be nice if the bulk create feature didn't strip out any of the text markup.

Thanks!

Yes please.

+1 for Description field to facilitate JIRA issue creation based on Confluence table on Requirements page.

Other fields are nice to have, but I can usually work around modifying the other fields via "bulk modify". The Summary and Description fields tend to be unique per JIRA issue, so these are the two fields that are most important to me when creating new JIRA issues.

We need this function/extension also.
Our process can be much faster so please make this wish comes true.

Best regards

Hello Cyrus,

You're correct.

Thank you,
Cyrus

Hello Atlassian,

This would be super helpful.

Thank you,
Cyrus

MAKE IT HAPPEN ATLASSIAN.

pls.

I'd love this feature. Only allowing 2 fields at the moment is stifling our productivity and requires touching the ticket multiple times after creation just to identify values which are currently present in the tables from which we create the tickets.

This is affecting our users as well. Our customers want to be able to create JIRA issues from Confluence, but are not able to do that since the Reporter field is required.

@Joel Bernerman - I think the version you were looking at was JIRA's version. In my mind the version that matters most in this situation is Confluence's version. The latest is 6.0.0-OD-2016.01.1-0003

I see that 2 fields can now be mapped in V6.0, which is a great start! Are there plans to make it possible to do more fields?

Im using the on demand-service and it looks like the "description" now is able to be mapped to any column as long as you use the create from table-function.
below this line at the bottom.
"Looks like you are creating issues from a table."

Great stuff.
I wonder how long its been there?

The system info says its version. 7.1.0-OD-02-030

The confluence product planning webinar (https://www.youtube.com/watch?v=bQdwy2x2eRo) shows some of this as being implemented. Has it been released? If so on what version? 5.8.8 just gives me summary.

Any update on this, Atlassian?

We currently use JIRA for an IT/Infrastructure change management process which follows a set workflow, with the end result being the creation of a Standard Operating Procedure document in Confluence. It would be great if we could actually write the Standard Operating Procedure in Confluence first, and have table fields map to our custom fields in JIRA. This way, we don't have to copy and paste data between JIRA and it means that the focus is on the documentation, rather than the change (which is a great help when documentation is often an afterthought).

An update would be much appreciated.

This would be a huge help - yes please.

agree with Shane, Summary and Description would be a great start but I would love to be able to match up everything.

I can see wanting everything at some point assuming the table columns matched the fields in JIRA.

For us right now though just the Summary and Description would be a huge win.

I see this issue ( suggestion ) being created almost a year back. When does even a part of this suggestion actually get implemented?
I would really like to see atleast description and component getting mapped to JIRA from confluence table.

I totally agree with :
These fields can be mapped to table header fields names so that mapping can be handled automatically, i.e. If I have Assignee and Title headers in my table, they can be added to JIRA issue fields automatically. If I have Description field in my table that would be added automatically as well.
Lets have the fields from the table header map to JIRA fields automatically and everyone would be free to use their own method/logic in creating JIRA issues from tables

The ability to populate more JIRA fields from within Confluence would be a massive improvement.

Ideally we would want to be to populate the full requirement table contents over to the jira story; the acceptance criteria, images, external URL's, estimates etc as indicated by Pierre-François Gonon. The ability to add the description automatically needs to be the priority though as the manual transfer will actually slow us down when creating project boards in JIRA.

Having the description populated automatically would be great.

this is a feature that will make the collabration between two product an awsome and will resolve and help manage feature -->Epic --> story

I completely agree with Pierre-François Gonon. This seems like a half done feature.

I would like to see the entire table be translated into details/attributes of a jira issue. Each column the user specify can be mapped to a field the user desires. Priority, versions, and labels are frequently used in my projects. I would like to be able to create issues thru a table of issue details with column headings matching project fields of my choice and be able to map those fields to the jira issue fields.

Hi, I am using this feature a lot to create tickets from Confluence. The main purpose of using Confluence and JIRA is to avoid double effort.
Here is how I proceed:
1. I create product requirements (using the confluence template) and I link it to the JIRA epic
2. For each product requirement (epic), I create a table of user stories in the confluence page: Name, description
3. Then I highlight the text and ask confluence to create all stories at once in JIRA. Very useful because that way I only enter name and description (acceptance criteria) once!

But, because it takes only Name and Description, I need to update one by one all the stories in JIRA to put more information: Priority, Version, etc.
Because of that I think we loose the benefit of creating from Confluence... It seems to me this feature is haffway done.

I suggest to add more fields (rather than just epic, name and description) or at least give the possibility of adding more field by programming something.
As the version is also in the "Product requirement" page property (same as the epic) it should be imported in JIRA.

Thank you for considering this improvment.

I could definitely live without the capability to schedule issues in upcoming sprints when working on requirements. As for other fields like assignee, description and story points, these fields should be able to be populated automatically as I see them as indespensable for planing releases. Else I see no value on use blue prints, if the requirements table columns can not be synchronized with the issue fields, then I rather plan stuff directly in the board. But please adapt your agile coach documentation to reality.

I don't completely agree with Bernados comments as I think there has to be a line drawn between what functionality lives in Confluence and what lives in JIRA. Personally I don't see sprint planning or estimations belonging in Confluence. For a story to be estimated it is pretty much confirmed 'ready' and therefore should be escalated to the backlog. This however is a minor point as I think the key thing is to eliminate the basic 'copy and paste' job that's involved in transferring the requirements from Confluence to JIRA. It all sounds great in the marketing stuff but it is still a laborious task in reality and I find it hard to believe Atlassian are 'eating their own dog food' with the functionality or they'd have 'finished' this off a long time ago.
Deliver value early by all means, but you have to iterate over the functionality or it just becomes a frustration that it's 'almost there'.

You have this nice agile coach documentation that sounds great, howerver when you try to apply it to real life it has a lot of holes, starting from this issue/improvement here.
If I read through it: https://www.atlassian.com/agile/requirements

I then go to the requirments blueprint and try to do what is suggested on the guide, I quickly realize that it makes no sense at all. If I can not estimate, assign stories to users or place the stories in different sprints, then is a waste of time... I love atlassian products but it is really frustrating to read this guides and realising that is just hype

+1, feature would be really useful, especially Estimation field, and planned date field.

I have a combo box field in JIRA and I can't create issues directly from confluence because this field is marked as required

Additional fields mapped from a table besides the summary would be ideal. My company would also need at least the description field and the time estimation field.

+1 for title & description but with the ability to select columns w/in a table (instead of all columns being included when multiple rows are selected)

+1 for Title & Description

+1 for Title and Description at least, customising other fields would be great

Ability to customize which fields to import would be ideal, but at a bare minimum we need to tie into the estimates field.

I think for MVP, it can be set up with some of the most commonly used fields: Assignee, Description, Priority, Issue Type. Those columns and carry-over to JIRA tickets would be a huge leap forward in making this functionality a time-saving additional to Confluence, vs. current state.

In the future, I think it could match the functionality that exists for bulk ticket creation via spreadsheet import, as it's essentially the same thing. This process utilizes a "wizard" to map fields from the spreadsheet (table) to existing fields - both default and custom - within the JIRA instance.

+1 for Title and Description

@Karine Martins: The problem is not the internationalization of the column name, but the internationalisation of the requirements table.

We have changed the product requirements template to expose german headlines, and I am sure you will find customers of Atlassian with french, spanish, italian, chinese, japanese, russian, hindi, kisuaheli headlines.

While not beeing the most wanted information, I am sure you can find another sample:

• The Jira field for "sprint" is a custom field (c0000xxx): You sure don't want this in your headline.
• The content of the sprint field is a number, not the name of the sprint.

The idea is straight forward, but it won't work in an international context and it won't work for all fields.
At least you must have the possibility to tag the headline with an optional macro, defining the jira link and content translation.

Thomas

(Sorry for writing with two accounts, my phone is logged on via g+, this is the myatlassian account.)

@smansour +1 on the Craig Goulden and cyrille cyrille 's comment.
There is no internationalization of the confluence column name, so you just have to make the mapping with the JIRA native default custom field name.
Keept it simple, it will work !!!
Karine

@cyrille This wont work for international customers.

+1 on the Craig Goulden's comment.
Keept it simple, if the column header title matches a CustomField then the injection should be done in JIRA, if not do nothing for this column.

Hope it will be soon added to a JIRA Version

+1 for Title and Description

Anything else is sugar on top. But we take the effort to create the "Use Case" description in the Requirements sheet, and yes, it would be smart not to have to copy those over one by one into the story-descriptions.

Even more lovely would be a content copy from the confluence page into the jira issue using a macro. This way, the story could be changed in confluence after the tasks have been created without the need of syncing the text, but again, that is also sugar.

+1 For the description

+1 For Title and Description as must have fields.

Following that priority would be good and probably not to hard to do.

Project specific stuff like epics and components can be left till after in Jira I think.

Specifically for my team, we would want this ability from the Product Requirements page, and the fields Description and Assignee would be the two most important. Ideally, the fields would remain linked as well, so if I update the Assignee on the Jira issue, the Assignee in the Product Requirement page would be updated to reflect that change. Same for Description, and any other fields that could be mapped.

Description, component, assignee would be amazing. Subtasks would also be helpful but that seems hard to do.

Description would be the one that would be key, though it would be nice to be able to select other columns to include as well.

We'd like to see component, assignee, and due date be added

For us primarily we would the description to be populated from the table. This at least lets us seed JIRA with details we have documented already in confluence.

Agree about Acceptance Criteria.