Auto populate fields when creating JIRA issues from Confluence

From a product and development planning perspective, I like the idea of being able to write up changes and tasks in a Confluence page and then being able to automatically create tickets based on the content of this page. Which is broadly what this macros does.

However, in its current state it will only take the text you highlight in one cell and add this as the Summary to the Jira ticket. And if you select to make multiple tickets, it will then generate tickets using the content of the same cell from the rows below. So you now have several tickets of the same type with only the Summary field populated, and if you need to add Description, Component, FixVersion, Epic, etc fields, then that has to be done manually.
So my request is to have the ability to have more fields, included custom fields, added automatically from other columns in the table.

As an example, consider the following example table with 5 columns, 1 header row, and 3 content rows where "h" is the header row, and RC is a cell in a row

With the current version I can highlight R1C1 in the first column and if I select to create multiple tickets I will get three tickets containing Summary "R1C1", "R2C1", and "R3C1" respectively.

What I suggested (just an initial thought on how to implement this), would be to:
1: Allow the user to add additional fields to the form. Imagine I add "Component", "FixVersion", and "Epic"
2: One option could then be specify in the form field "Component" to contain "$h2", "FixVersion" to contain "$h3", and "Epic" to contain "$h5"
3: The macro could then be extended to recognise "$h2" as column header, and then add the corresponding cell value into this field per ticket.
4: I would then have tickets containing:
Ticket 1:

• Summary: R1C1
• Component: R1C2
• FixVersion: R1C3
• Epic: R1C5

Ticket 2:

• Summary: R2C1
• Component: R2C2
• FixVersion: R2C3
• Epic: R2C5

Ticket 3:

• Summary: R3C1
• Component: R3C2
• FixVersion: R3C3
• Epic: R3C5

Hope that clarifies. The above example is obviously down to implementation, however the key is to achieve an outcome that allows me to create a more complete ticket based on content from a Confluence table.