Uploaded image for project: 'Confluence Data Center'
  1. Confluence Data Center
  2. CONFSERVER-31867

Ability to map more fields from a Confluence table into a Jira issue when highlighting and creating issues

    • 14
    • 46
    • We collect Confluence feedback from various sources, and we evaluate what we've collected when planning our product roadmap. To understand how this piece of feedback will be reviewed, see our Implementation of New Features Policy.

      NOTE: This suggestion is for Confluence Server. Using Confluence Cloud? See the corresponding suggestion.

      Confluence 5.4 shipped with the ability to highlight text in a table and bulk-create JIRA issues. This only supports the "Summary" field in JIRA.

      We've been thinking about improving this feature to allow you to map other columns form your tables in Confluence into JIRA. The difficulty here is in the complexity this exposes and becomes even more tedious when it comes to custom fields an required fields.

      So we'd love to hear form you. Are you interested in this feature? If so...

      • What types of documents do you want to do this in? (Requirements, testing....)
      • Do you want all the fields or is it the same ones over and over again? E.g. is "Description" the majority of what you are after?

      Any feedback would be greatly appreciated

            [CONFSERVER-31867] Ability to map more fields from a Confluence table into a Jira issue when highlighting and creating issues

            Hi All,

            Our Jcreate app adds the ability to map Confluence table columns to Jira issue fields, you really should give it a try!

            Paz Methoda

            Paz Grimberg added a comment - Hi All, Our Jcreate app adds the ability to map Confluence table columns to Jira issue fields, you really should give it a try! Paz Methoda

            I would use it for Requirements gathering template for specific set of fields to populate into an issues. Probably ones like, Labels, Priority. I would also think it make a lot of sense for the Jira ticket to automatically link back to the source product requirement table/page in confluence.

            Phil Merrell added a comment - I would use it for Requirements gathering template for specific set of fields to populate into an issues. Probably ones like, Labels, Priority. I would also think it make a lot of sense for the Jira ticket to automatically link back to the source product requirement table/page in confluence.

            HI, 

            We have built an addon that provides the ability to have full issue screen and configuration in Confluence

            see: https://marketplace.atlassian.com/apps/1224226/jcreate?hosting=server&tab=overview

            Best regards,

            Yaniv

            yaniv.shoshani added a comment - HI,  We have built an addon that provides the ability to have full issue screen and configuration in Confluence see: https://marketplace.atlassian.com/apps/1224226/jcreate?hosting=server&tab=overview Best regards, Yaniv

            Seppe Uvin added a comment -

            This would greatly increase integration benefits of Jira & Confluence in our company. For example, when we do meeting notes internally or with suppliers we make our meeting notes in Confluence. Then, the idea is to make a table in the meeting notes which describes needed actions (example: supplier needs to look into a problem, an internal team needs to look into a user story...). The issues would be made straight from Confluence so they are directly integrated with Jira and our Scrum/Kanban Boards for our teams. This reduces admin for status follow-up greatly since the Confluence report will just automatically update the Jira issue status in the meeting report for our next meeting.

            We have many teams in a single project, each with their own Boards. Our team Boards show only issues relevant to a certain team by filtering on some standard & custom fields. Our suppliers also have access to JIRA, so issues related to them are mapped using different fields. Also, there's a high degree of classification needed because we have many many issues. For that we use Epic Links, labels or Components for example.

            Therefore the current functionality to make Jira issues from Confluence is too limited in our company. We would need the option to map more columns from a table to fields (for example a column "labels" or "Components" or any custom field). Some kind of templates/applied fields would also help, since within each Confluence page we usually have a lot of fields that should be the same for all the created tasks in that page.

            Seppe Uvin added a comment - This would greatly increase integration benefits of Jira & Confluence in our company. For example, when we do meeting notes internally or with suppliers we make our meeting notes in Confluence. Then, the idea is to make a table in the meeting notes which describes needed actions (example: supplier needs to look into a problem, an internal team needs to look into a user story...). The issues would be made straight from Confluence so they are directly integrated with Jira and our Scrum/Kanban Boards for our teams. This reduces admin for status follow-up greatly since the Confluence report will just automatically update the Jira issue status in the meeting report for our next meeting. We have many teams in a single project, each with their own Boards. Our team Boards show only issues relevant to a certain team by filtering on some standard & custom fields. Our suppliers also have access to JIRA, so issues related to them are mapped using different fields. Also, there's a high degree of classification needed because we have many many issues. For that we use Epic Links, labels or Components for example. Therefore the current functionality to make Jira issues from Confluence is too limited in our company. We would need the option to map more columns from a table to fields (for example a column "labels" or "Components" or any custom field). Some kind of templates/applied fields would also help, since within each Confluence page we usually have a lot of fields that should be the same for all the created tasks in that page.

            Adding at least some Jira system fields would be highly desirable. While Resolution field is not really applicable here, Labels field should be added at minimum. 

            Mikko Hanninen added a comment - Adding at least some Jira system fields would be highly desirable. While Resolution field is not really applicable here, Labels field should be added at minimum. 

            Interesting if the feature would include date fields. As Atlassian showcase is to start project initiation (documentation) from Confluence, it would make sense that at least all date fields should be supported on creation of Jira issues. For example start and end date so you can create multiple tasks for use in planning apps like Big Picture, Advanced Roadmaps etc.

            Robert Bennemeer added a comment - Interesting if the feature would include date fields. As Atlassian showcase is to start project initiation (documentation) from Confluence, it would make sense that at least all date fields should be supported on creation of Jira issues. For example start and end date so you can create multiple tasks for use in planning apps like Big Picture, Advanced Roadmaps etc.

            Mechee added a comment - - edited

            Should we clone and reopen this issue? I don't believe something I've been watching and people are actively voting on should be 'not considered' without some type of explanation from the PO/PM....

             
            jmillman made changes - 01/Feb/2018 3:39 PM

            PM Reviewed   02/Feb/2018
            Status Reviewing [ 11773 ] Not Being Considered [ 11776 ]

            Mechee added a comment - - edited Should we clone and reopen this issue? I don't believe something I've been watching and people are actively voting on should be 'not considered' without some type of explanation from the PO/PM....   jmillman  made changes - 01/Feb/2018 3:39 PM PM Reviewed   02/Feb/2018 Status Reviewing [ 11773 ] Not Being Considered [ 11776 ]

            Czomba László added a comment - - edited

            Hi community,

            I hope you don't mind this intrusion, but I encourage you to check out our new app.
            IssueCreate works as many of you described above. It is able to create multiple issues from a table with almost any type of fields.
            You can find more information on the marketplace, or on the documentation site.
             

            Best regards

            Czomba László added a comment - - edited Hi community, I hope you don't mind this intrusion, but I encourage you to check out our new app. IssueCreate works as many of you described above. It is able to create multiple issues from a table with almost any type of fields. You can find more information on the marketplace , or on the documentation site.   Best regards

            Hey!  I voteing on this   

            Maciej Lad added a comment - Hey!  I voteing on this   

            Hello Atlassian, 

            Its more than 6 years. how much time you need to develop this basic and imp functionality?

            Regards,

            Abhi

            Abhishek Singh added a comment - Hello Atlassian,  Its more than 6 years. how much time you need to develop this basic and imp functionality? Regards, Abhi

            Hi there, it's a great idea to extend this (already impressive) functionality. Typical customer requests contain fields such as assignee (could be mapped easily by using @mention in the Confluence table), priority (requires mapping between the cell text and Jira prio values), original estimate (a duration like '4d 2h'), and labels. If a field-level mapping is implemented, it should be generic so it can also be applied to custom fields. People would love to see a preview of what is going to be created in Jira before it actually happens. The respective view could also be used to indicate and interactively correct mapping problems.

             

            Johannes Franke added a comment - Hi there, it's a great idea to extend this (already impressive) functionality. Typical customer requests contain fields such as assignee (could be mapped easily by using @mention in the Confluence table), priority (requires mapping between the cell text and Jira prio values), original estimate (a duration like '4d 2h'), and labels. If a field-level mapping is implemented, it should be generic so it can also be applied to custom fields. People would love to see a preview of what is going to be created in Jira before it actually happens. The respective view could also be used to indicate and interactively correct mapping problems.  

            It would be helpful to have the ability to have all fields available regardless of custom or not. This gives the teams the ability to reference the fields that they want/need depending on the document they are creating. Typically this is used for design docs but we have our own template so it is not a specific prepackaged blueprint or template. For sure we have to have the ability to do required fields otherwise there is no ability to create the issue. This would be a huge benefit to the integration between Jira and Confluence. We are a Microsoft house and the biggest thing that keeps Atlassian in our stack of tools is the integration between Jira and Confluence. The more integration points you can make, the more value you offer.

            Troy Johnson added a comment - It would be helpful to have the ability to have all fields available regardless of custom or not. This gives the teams the ability to reference the fields that they want/need depending on the document they are creating. Typically this is used for design docs but we have our own template so it is not a specific prepackaged blueprint or template. For sure we have to have the ability to do required fields otherwise there is no ability to create the issue. This would be a huge benefit to the integration between Jira and Confluence. We are a Microsoft house and the biggest thing that keeps Atlassian in our stack of tools is the integration between Jira and Confluence. The more integration points you can make, the more value you offer.

            Jan Dupont added a comment -

            I don't really need the extra mapping aside from the summary field, but for us it's very important that we can at least create an issue with required custom fields. Today we can't longer use this feature because of that and it's a great loss.

            Jan Dupont added a comment - I don't really need the extra mapping aside from the summary field, but for us it's very important that we can at least create an issue with required custom fields. Today we can't longer use this feature because of that and it's a great loss.

            This issue was created in 2013. Come on Atlassian! Adding additional fields for things like assignee, component, etc should be something that exists. Understandable with the complexities on custom fields.

            Brian Espinosa added a comment - This issue was created in 2013. Come on Atlassian! Adding additional fields for things like assignee, component, etc should be something that exists. Understandable with the complexities on custom fields.

            Agreed - it is duplicating work to create an issue in Confluence and then having to edit the issue in Jira to set the assignee for example

            Evanna McMahon added a comment - Agreed - it is duplicating work to create an issue in Confluence and then having to edit the issue in Jira to set the assignee for example

            YES, we need this

            Chris Thach added a comment - YES, we need this

            Smita added a comment -

            Yes, I vote +1 for all the requests here. It would be great to have the columns mapped to major Jira fields like Assignee, Estimate, Sprint, Epic etc. The whole purpose of creating the tasks from Confluence is to reduce the duplication of effort and if we cannot achieve that then its not great.

             

            The inability to modify anything in the macro makes it look so bad, there should be some way to make everyone's life easier. Please implement this feature 

            Smita added a comment - Yes, I vote +1 for all the requests here. It would be great to have the columns mapped to major Jira fields like Assignee, Estimate, Sprint, Epic etc. The whole purpose of creating the tasks from Confluence is to reduce the duplication of effort and if we cannot achieve that then its not great.   The inability to modify anything in the macro makes it look so bad, there should be some way to make everyone's life easier. Please implement this feature 

            Same here. I can understand that not every fancy field can have a intuitive mapping from a table to the entry in the Jira issue, but plain text fields, date fields, and users should be no problem.

            The standard dialog that requests you to map a table heading to the description or summary field can still be the "average user" function.
            But for advanced users that could be extended to an implicit conversion of table headings to available Jira fields. Maybe a small checkbox "mapTable columns to Jira fields"

            Currently it is simply annoying to have a table with Summary, Description and DueDate and you have to go to every single issue and add the DueDate manually because only Summary and Description are considered

            Sebastian Tschörner added a comment - Same here. I can understand that not every fancy field can have a intuitive mapping from a table to the entry in the Jira issue, but plain text fields, date fields, and users should be no problem. The standard dialog that requests you to map a table heading to the description or summary field can still be the "average user" function. But for advanced users that could be extended to an implicit conversion of table headings to available Jira fields. Maybe a small checkbox "mapTable columns to Jira fields" Currently it is simply annoying to have a table with Summary, Description and DueDate and you have to go to every single issue and add the DueDate manually because only Summary and Description are considered

            I agree that this is essential. Creating a list of requirement in Confluence to then have to go manually add other fields is very counterproductive. I would like to have a standard Confluence table for X activity and every time that activity is required, to duplicate the list and then create my series of user stories with all pre-filled details. 

            Irene C. East added a comment - I agree that this is essential. Creating a list of requirement in Confluence to then have to go manually add other fields is very counterproductive. I would like to have a standard Confluence table for X activity and every time that activity is required, to duplicate the list and then create my series of user stories with all pre-filled details. 

            Speaking for many Confluence & Jira customers: This is an essential feature to present a "smooth" integration of Confluence and Jira without doing duplicate work (as it currently is).

            Desired workflow: 

            1. Create a table with columns representing (at least all mandatory) fields in Jira
            2. Create issues automatically in Jira without the need to edit the issues afterwards

            Thanks a lot in advance.

             

            Andrea Roßkamp [Communardo] added a comment - Speaking for many Confluence & Jira customers: This is an essential feature to present a "smooth" integration of Confluence and Jira without doing duplicate work (as it currently is). Desired workflow:  Create a table with columns representing (at least all mandatory) fields in Jira Create issues automatically in Jira without the need to edit the issues afterwards Thanks a lot in advance.  

            Joe added a comment -

            This functionality, creating tickets from Confluence pages, appears to be completely broken for me now, using Jira and Confluence cloud.

            Joe added a comment - This functionality, creating tickets from Confluence pages, appears to be completely broken for me now, using Jira and Confluence cloud.

            Agree, would like to see this considered. The existing feature is very powerful but falls short when manual copy and paste is required to transition the rest of the requirement to the Jira story. Additional field mapping would certainly add value.

            Jonathan Gebarowski added a comment - Agree, would like to see this considered. The existing feature is very powerful but falls short when manual copy and paste is required to transition the rest of the requirement to the Jira story. Additional field mapping would certainly add value.

            This would be amazing if we could map additional fields over. 

            Samantha VanSlyke added a comment - This would be amazing if we could map additional fields over. 

            It really is a simple request - it will be great to fill out the requirements table on confluence with all fields that we want the Jira issue to have populated, and for the create issue icon to pull through the correct values per field when highlighting a table row in read-mode. Perhaps it could use the table field name to find the Jira issue field name to populate ? Really don't understand why this isn't being considered as an enhancement despite the levels of interest ..

            Gursharan Kaur added a comment - It really is a simple request - it will be great to fill out the requirements table on confluence with all fields that we want the Jira issue to have populated, and for the create issue icon to pull through the correct values per field when highlighting a table row in read-mode. Perhaps it could use the table field name to find the Jira issue field name to populate ? Really don't understand why this isn't being considered as an enhancement despite the levels of interest ..

            Jan-Peter Rusch added a comment - - edited

            The description of this issue is:

            Ability to map more fields from a Confluence table into a JIRA issue when highlighting and creating issues

            I might be proven wrong, but following the comment thread, I guess most users want to have more than the summary field automapped to a new Jira issue instead of having more fields available to be filled out when creating the new issue.

            Jan-Peter Rusch added a comment - - edited The description of this issue is: Ability to map more fields from a Confluence table into a JIRA issue when highlighting and creating issues I might be proven wrong, but following the comment thread, I guess most users want to have more than the summary field automapped to a new Jira issue instead of having more fields available to be filled out when creating the new issue.

            The subject is literally "map more fields" and I showed that the functionality exists to "map more fields", granted making all fields required is not something everyone can go do. You go in depth explaining a feature I had just taken a screenshot saying 'it has nothing to do with this issue'.

            I disagree.

            Steven Behnke added a comment - The subject is literally "map more fields" and I showed that the functionality exists to "map more fields", granted making all fields required is not something everyone can go do. You go in depth explaining a feature I had just taken a screenshot saying 'it has nothing to do with this issue'. I disagree.

            Steven, this issue is all about MAPPING MORE FIELDS than just a issue description, when generating an issue by highlighting text in a Confluence page. With any current release of Confluence you will only get the issue summary set from the highlighted text or table rows. There's no mapping of the issue type, no mapping of priority, no mapping of ... you name it...

            I didn't call you wrong, but the function you describe in your screenshots has nothing to do with a intend of this issue.

            Jan-Peter Rusch added a comment - Steven, this issue is all about MAPPING MORE FIELDS than just a issue description, when generating an issue by highlighting text in a Confluence page. With any current release of Confluence you will only get the issue summary set from the highlighted text or table rows. There's no mapping of the issue type, no mapping of priority, no mapping of ... you name it... I didn't call you wrong, but the function you describe in your screenshots has nothing to do with a intend of this issue.

            My apologies

            Steven Behnke added a comment - My apologies

            Steven - that was directed at Atlassian, not you!

            Kate Hanna added a comment - Steven - that was directed at Atlassian, not you!

            To be frank, I am a system administrator and a customer.

            Steven Behnke added a comment - To be frank, I am a system administrator and a customer.

            To be quite frank, you need to fix this functionality first.  Until I can highlight User Story text in the table Requirements Confluence page and reliably get the User Story(ies) added to Jira and referenced on the Confluence page in one action, being able to auto-fill more fields in the Jira story is neither here nor there. 

            Kate Hanna added a comment - To be quite frank, you need to fix this functionality first.  Until I can highlight User Story text in the table Requirements Confluence page and reliably get the User Story(ies) added to Jira and referenced on the Confluence page in one action, being able to auto-fill more fields in the Jira story is neither here nor there. 

            Jan-Peter, my second screenshot clearly and visibly shows me highlighting a table and creating a ticket from said table with additional fields provided by the Field Configuration requirements I spoke of. Please consider viewing the material before calling me wrong.

            Steven Behnke added a comment - Jan-Peter, my second screenshot clearly and visibly shows me highlighting a table and creating a ticket from said table with additional fields provided by the Field Configuration requirements I spoke of. Please consider viewing the material before calling me wrong.

            ok sry. thought that would be a part of it

            Mark Oliver Utz added a comment - 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.

            Jan-Peter Rusch added a comment - 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

            Mark Oliver Utz added a comment - 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.

            Steven Behnke added a comment - 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

            Mark Oliver Utz added a comment -     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.

            Steven Behnke added a comment - 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. 

             

             

            Mark Oliver Utz added a comment - 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.

            Gursharan Kaur added a comment - 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.

            Jenny (Inactive) added a comment - 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! 

            Kate Hanna added a comment - @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! 

            carson.price1035477722 added a comment -

            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. 

            carson.price1035477722 added a comment - 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. 

            Kate Hanna added a comment -

            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.

            Kate Hanna added a comment - 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.

            Amanda D Sa added a comment - 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.

            Patrick van der Rijst added a comment - What do you mean with "Details"? Summary and description are mapped actually.

            We would need the Summary and the Details

            Dr. Richard added a comment - 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.

            Carlotta Simonson added a comment - +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!

            Support NEOFI added a comment - 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.

            Hung Nguyen added a comment - 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. 

            Keith Winton added a comment - 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

            Charlie Misonne added a comment - 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

            Kevin Reddig added a comment - 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?

            Dave Paulson added a comment - 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. 

            Pat Saunders added a comment - 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

            Mark Willmann added a comment - Acceptance Criteria would help us dramatically

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

            Thanks!

            Aleš Leskovar added a comment - Is this issue already in roadmap ? When can we expect to see this in live ? Thanks!

            Sam Ensogna added a comment - - edited

            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.

            Sam Ensogna added a comment - - edited 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.

            Sebastiaan added a comment -

            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.

            Sebastiaan added a comment - 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.

            Jordan M. Pflum added a comment - 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.

              Unassigned Unassigned
              smansour Sherif Mansour
              Votes:
              474 Vote for this issue
              Watchers:
              294 Start watching this issue

                Created:
                Updated: