Page History
UI Expand | ||
---|---|---|
| ||
|
Iterating Issue
...
History
Changes to Issues are registered in the Issue History, but Because it is not known in advance how many changes are going to be made.
You comments exist for an issue, you can iterate a section over all the comments on an issueHistory entries of an Issue. This allows you to create a table that dynamically grows according to the number of existing commentschanges done.
The notation is:
Field | Description | ||||||||
---|---|---|---|---|---|---|---|---|---|
HistoryEntriesCount | The number of changes made | ||||||||
Author | The | ||||||||
AuthorFullName | The full name of the author of the comment | ||||||||
Body | The comment | ||||||||
Created | The date the comment was posted | GroupLevel | |||||||
user who made the change | |||||||||
Created | Date of the change | ||||||||
ChangedItemsCount | The number of fields changed in the current change | ||||||||
ChangedItems |
| ||||||||
Code Block | ||||
---|---|---|---|---|
| ||||
#{for commentshistoryEntries} ${Commentsfullname:HistoryEntries[n].Author} made changes ${Comments[n].AuthorFullName} ${Comments[n].Body} ${dateformat("dd-MM-dateformat("dd-MM-yyyy HH:mm:ss"):CommentsHistoryEntries[n].Created} ${Comments#{for ch=HistoryEntries[n].GroupLevel} #{end} or #{for <VariableName>=CommentsCountChangedItemsCount} Content and Issue Mappings. ExampleField Name: ${CommentsHistoryEntries[VariableNamen].Field} #{end} |
The documents below demonstrate examples both in Word and Excel template that iterates over all the issue comments.
Iterating Issue Worklogs
ChangedItems[ch].Field}
Old Value: ${HistoryEntries[n].ChangedItems[ch].From}
New Value: ${HistoryEntries[n].ChangedItems[ch].To}
#{end}
#{end}
or
#{for <VariableName>=HistoryEntriesCount}
Content and Issue History Mappings. Example:${fullname:HistoryEntries[VariableName].Field}
#{end} |
The documents below demonstrate examples both in Word and Excel templates that iterate over all the Issue comments.
...
Iterating Xray Issue History
Changes related to Xray fields in Xray Issues are registered in a separate tab named Xray History, as changes to these fields can not be included with the Issue changes. For this reason, there is another way of iterating Xray history changes. Just like with Issue changesBecause it is not known in advance how many work logs exist for an issue, you can iterate a section over all the work logs Xray history entries of an issueIssue. This allows you to create a table that dynamically grows according to the number of existing worklogschanges done.
The notation is:
Field | Description | ||||||
---|---|---|---|---|---|---|---|
XrayHistoryEntriesCount | The | ||||||
number of | |||||||
changes made | |||||||
Action | The | ||||||
Comment | The comment of the worklog | ||||||
Created | The date the worklog was created | ||||||
Date Started | The date the worklog was started | ||||||
Time Spent | The time spent in seconds | TimeSpentFormatted | The time spent as displayed on Jira|||||
action that originated the changes | |||||||
User | The user who made the change | ||||||
Date | Date of the change | ||||||
Version | The Xray Test Version where the changes were made (if applicable) | ||||||
XrayChangedItemsCount | The number of fields changed in the current change | ||||||
XrayChangedItems |
|
Code Block | ||||
---|---|---|---|---|
| ||||
#{for worklogsXrayHistoryEntries} ${Worklogsfullname:XrayHistoryEntries[n].AuthorUser} made changes ${Worklogsdateformat("dd-MM-yyyy HH:mm:ss"):XrayHistoryEntries[n].AuthorFullNameDate} ${Worklogs#{for ch=XrayHistoryEntries[n].CommentXrayChangedItemsCount} Field ${dateformat("dd-MM-yyyy HH:mm:ss"):WorklogsName: ${XrayHistoryEntries[n].CreatedXrayChangedItems[ch].Field} Changes: ${dateformat("dd-MM-yyyy HH:mm:ss"):WorklogsXrayHistoryEntries[n].Date Started} XrayChangedItems[ch].Changes} ${Worklogs[n].Time Spent} ${Worklogs[n].TimeSpentFormatted} #{end} #{end} or #{for <VariableName>=WorklogsCountXrayHistoryEntriesCount} Content and WorklogXray Issue History Mappings. Example: ${Worklogsfullname:XrayHistoryEntries[VariableName].Field} #{end} |
The documents below demonstrate examples both in Word and Excel
...
templates that
...
iterate over all the
...
Issue comments.
...
Iterating_Xray_Issue_History.docx
...
Iterating_Xray_Issue_History.xlsx
...
Iterating Issue
...
Comments
Because it is not known in advance how many components comments exist for an issueIssue, you can iterate a section over all the components of comments on an issueIssue. This allows you to create a table that dynamically grows according to the number of existing componentscomments.
The notation is:
Comments Fields | Description | Name||||
---|---|---|---|---|---|
Author | The | ||||
author of the | |||||
comment | |||||
AuthorFullName | The | descriptionfull name of the | componentLead | The nameauthor of the | component leadcomment |
Body | The comment | ||||
Created | ID of the componentProjectIdThe | project ID of the componentdate the comment was posted | |||
GroupLevel | The group level of the comment | AssigneeType | The assignee type of the component
Code Block | ||||
---|---|---|---|---|
| ||||
#{for componentscomments} ${ComponentsComments[n].NameAuthor} ${ComponentsComments[n].DescriptionAuthorFullName} ${fullname:ComponentsComments[n].LeadBody} ${Components[n].Iddateformat("dd-MM-yyyy HH:mm:ss"):Comments[n].Created} ${ComponentsComments[n].ProjectIdGroupLevel} #{end} or #{for <VariableName>=CommentsCount} Content and Issue Mappings. Example: ${ComponentsComments[nVariableName].AssigneeTypeField} #{end} |
The documents below demonstrate examples both in Word and Excel
...
templates that
...
iterate over all the
...
Issue comments.
...
...
...
Iterating Issue
...
Worklogs
Because it is not known in advance how many Status Transitions worklogs exist for an issueIssue, you can iterate a section over all the Status Transitions work logs of an issueIssue. This allows you to create a table that dynamically grows according to the number of existing status transitionsworklogs.
The notation is:
Status Transitions Worklogs Fields | Description |
---|---|
Author | The author of the status transitionworklog |
Created AuthorFullName | The date the status transition was performed |
OldStatus | The old status of the status transition |
NewStatus | The new status of the status transition |
full name of the author of the worklog | |
Comment | The comment of the worklog |
Created | The date the worklog was created |
Date Started | The date the worklog was started |
Time Spent | The time spent in seconds |
TimeSpentFormatted | The time spent as displayed on Jira |
Code Block | ||||
---|---|---|---|---|
| ||||
Code Block | ||||
| ||||
#{for statusTransitionsworklogs} ${StatusTransitionsWorklogs[n].Author} ${Worklogs[n].AuthorFullName} ${Worklogs[n].Comment} ${dateformat("dd-MM-yyyy HH:mm:ss"):StatusTransitionsWorklogs[n].Created} ${StatusTransitionsdateformat("dd-MM-yyyy HH:mm:ss"):Worklogs[n].OldStatusDate Started} ${Worklogs[n].Time Spent} ${StatusTransitionsWorklogs[n].NewStatusTimeSpentFormatted} #{end} or #{for <VariableName>=StatusTransitionsCountWorklogsCount} Content and StatusTransitionsWorklog Mappings. Example: ${StatusTransitionsWorklogs[VariableName].Field} #{end} |
The documents below demonstrate examples both in Word and Excel template templates that iterates iterate over all the issue status transitionsIssue worklogs.
Iterations_StatusTransitionsWorklogs.docx
Iterations Iterations_StatusTransitionsWorklogs.xlsx
...
Iterating Issue
...
Components
Because it is not known in advance how many Images can components exist for an issue (as an attachment)Issue, you can iterate a section over all the attached images components of an issue to get some metadata about themIssue. This allows you to create a table that dynamically grows according to the number of existing imagescomponents.
The notation is:
Attachments Images Components Fields | Description | ID||
---|---|---|---|
Name | The | IDname of the | attached imagecomponent |
ImageDescription | The image description of the attached imagecomponent | ||
NameLead | The name of the attached imagecomponent lead | ||
SizeId | The size ID of the attached imagecomponent | ||
HumanReadableSizeProjectId | The size project ID of the attached imagecomponent | ||
AuthorAssigneeType | MimeType | The author of the attached image | |
Created | The date the attached image was created | ||
The assignee type of the attached image | |||
ThumbnailURL | The image thumbnail URL. | ||
component |
Code Block | ||||
---|---|---|---|---|
| ||||
#{for imagescomponents} ${ImagesComponents[n].Image|maxwidth=150|maxheight=150} ${Images[n].Name} ${ImagesComponents[n].IDDescription} ${Imagesfullname:Components[n].SizeLead} ${ImagesComponents[n].HumanReadableSizeId} ${ImagesComponents[n].AuthorProjectId} ${dateformat("dd-MM-yyyy HH:mm:ss"):ImagesComponents[n].CreatedAssigneeType} ${Images[n].MimeType} ${Images[n].ThumbnailURL} #{end} or #{for <VariableName>=ImagesCount} Content and Images Mappings. Example: ${Images[VariableName].Field} #{end}#{end} |
The The documents below demonstrate examples both in Word and Excel template templates that iterates iterate over all the issue attached imagesIssue components.
Iterations_AttachedImages Iterating_Issue_Components.docx
Iterations_AttachedImages
Iterating_Issue_Components.xlsx
Info |
---|
Document Generator will automatically read the EXIF orientation property of an image and rotate it to its correct orientation. You can turn this off by adding |
You can use the mappings "width" and "height" to define the exact width and height of the printed image.
...
Iterating Issue Status Transitions
Because it is not known in advance how many Status Transitions exist for an Issue, you can iterate a section over all the Status Transitions of an Issue. This allows you to create a table that dynamically grows according to the number of existing status transitions.
The notation is:
Status Transitions Fields | Description |
---|---|
Author | The author of the status transition |
Created | The date the status transition was performed |
OldStatus | The old status of the status transition |
NewStatus | The new status of the status transition |
Code Block | ||||
---|---|---|---|---|
| ||||
Code Block | ||||
| ||||
#{for imagesstatusTransitions} ${ImagesStatusTransitions[n].Image|width=150|height=150Author} #{end} |
These values are in pixels and if you only define one of them the image will be rescaled.
Info |
---|
Note that, if you use both maxWidth and width mappings, only the max value will be read. The same behavior happens with height and maxHeight. |
Iterating Issue Attachments
${dateformat("dd-MM-yyyy HH:mm:ss"):StatusTransitions[n].Created}
${StatusTransitions[n].OldStatus}
${StatusTransitions[n].NewStatus}
#{end}
or
#{for <VariableName>=StatusTransitionsCount}
Content and StatusTransitions Mappings. Example: ${StatusTransitions[VariableName].Field}
#{end} |
The documents below demonstrate examples both in Word and Excel templates that iterate over all the Issue status transitions.
Iterations_StatusTransitions.docx
Iterations_StatusTransitions.xlsx
...
Iterating Issue Attached Images
Because it is not known in advance how many images can exist on an Issue (as an attachment)Because it is not known in advance how many attachments exist in an issue, you can iterate a section over all the attachments of an issueattached images of an Issue to get some metadata about them. This allows you to create a table that dynamically grows according to the number of existing attachmentsimages.
The notation is:
Attachments Images Fields | Description | |
---|---|---|
ID | The ID of the | attachmentattached image |
NameImage | The name image of the attachmentattached image | |
Name | The name of the attached image | |
SizeAuthor | The author size of the attachmentattached image | |
AuthorFullNameHumanReadableSize | The full name size of the attached image | |
Author | The author of the attachmentattached image | |
Created | The date the attachment attached image was created | |
SizeMimeType | The size type of the attachmentattached imageHumanReadableSize | |
ThumbnailURL | The | formatted size of the attachment|
MimeType | The type of attachment | |
image thumbnail URL. |
Code Block | ||||
---|---|---|---|---|
| ||||
#{for attachmentsimages} ${AttachmentsImages[n].IDImage|maxwidth=150|maxheight=150} ${AttachmentsImages[n].Name} ${AttachmentsImages[n].AuthorID} ${AttachmentsImages[n].Size} ${Images[n].HumanReadableSize} ${Images[n].AuthorFullNameAuthor} ${dateformat("dd-MM-yyyy HH:mm:ss"):AttachmentsImages[n].Created} ${AttachmentsImages[n].SizeMimeType} ${AttachmentsImages[n].HumanReadableSizeThumbnailURL} ${Attachments[n].MimeType} #{ #{end} or #{for <VariableName>=AttachmentsCountImagesCount} Content and IssueImages Mappings. Example: ${AttachmentsImages[VariableName].Field} #{end} |
The documents below demonstrate examples both in Word and Excel template templates that iterates iterate over all the issue attachmentsIssue attached images.
Iterations_AttachmentsAttachedImages.docx
Iterations_AttachmentsAttachedImages.xlsx
Iterating Issue Labels
Because it is not known in advance how many labels exist in an issue, you can iterate a section over all the labels of an issue. The notation is:
...
Info |
---|
Document Generator will automatically read the EXIF orientation property of an image and rotate it to its correct orientation. You can turn this off by adding |
You can use the mappings width
and height
to define the exact width and height of the printed image.
Code Block | ||||
---|---|---|---|---|
| ||||
#{for images | ||||
Code Block | ||||
#{for labels} ${LabelsImages[n].NameImage|width=150|height=150} # #{end} or #{for <VariableName>=LabelsCount} ${Labels[VariableName].Name} #{end} |
The documents below demonstrate examples both in Word and Excel template that iterates over all the issue comments.
Iterating Fix Versions of an Issue
You can iterate over all fix versions to which the issue belong to. The notation is:
...
These values are in pixels and if you only define one of them the image will be rescaled.
Info |
---|
If you use the |
...
Iterating Issue Attachments
Because it is not known in advance how many attachments exist in an Issue, you can iterate a section over all the attachments of an Issue. This allows you to create a table that dynamically grows according to the number of existing attachments.
The notation is:
Attachments Fields | Description |
---|---|
ID | The ID of the attachment |
Name | The name of the attachment |
Author | The author of the attachment |
AuthorFullName | The full name of the author of the attachment |
Created | The date the attachment was created |
Size | The size of the attachment |
HumanReadableSize | The formatted size of the attachment |
MimeType | The type of attachment |
Code Block | ||||
---|---|---|---|---|
| ||||
Code Block | ||||
| ||||
#{for FixVersions} ${FixVersions attachments} ${Attachments[n].ID} ${Attachments[n].Name} ${FixVersionsAttachments[n].DescriptionAuthor} ${dateformat(“dd-MM-yyyy”):FixVersionsAttachments[n].Start dateAuthorFullName} ${dateformat(“dd"dd-MM-yyyy”yyyy HH:mm:ss"):FixVersionsAttachments[n].Release date} ${FixVersionsCreated} ${Attachments[n].Size} ${Attachments[n].ArchivedHumanReadableSize} ${FixVersionsAttachments[n].ReleasedMimeType} #{end} or #{for <VariableName>=FixVersionsCountAttachmentsCount} Content and Versions Issue Mappings. Example: ${FixVersionsAttachments[VariableName].Field} #{end} |
The documents below demonstrate examples both in Word and Excel template templates that iterates iterate over all the issue fix versionsIssue attachments.
Iterating_Issue_FixVersions Iterations_Attachments.docx
Iterating_Issue_FixVersions
...
Iterating
...
Issue
...
Labels
Because it is not known in advance how many labels exist in an Issue, you can iterate a section over all the labels of an Issue.
You can iterate over all affected versions to which the issue belong to. The notation is:
Versions Attachments Fields | Description |
---|---|
Name | The version name |
Description | The version description |
Start date | Starting date of the version label |
Release date | Release date of the version |
Archived | Boolean that indicates if the version is archived or not |
Released | Boolean that indicates if the version is released or not |
Code Block | ||||
---|---|---|---|---|
#{for labels}
${Labels[n].Name}
#{end}
or
#{for <VariableName>=LabelsCount}
${Labels[VariableName | ||||
Code Block | ||||
| ||||
#{for AffectedVersions} ${AffectedVersions[n].Name} ${AffectedVersions[n].Description} ${dateformat(“dd-MM-yyyy”):AffectedVersions[n].Start date} ${dateformat(“dd-MM-yyyy”):AffectedVersions[n].Release date} ${AffectedVersions[n].Archived} ${AffectedVersions[n].Released} #{end} or #{for <VariableName>=AffectedVersionsCount} Content and Versions Issue Mappings. Example: ${AffectedVersions[VariableName].Field} #{end} |
The documents below demonstrate examples both in Word and Excel template that iterates over all the issue affected versions.
Iterating_Issue_AffectedVersions.docx
Iterating_Issue_AffectedVersions.xlsx
Iterating Project Versions
You can iterate over all project versions to which the issue belong to. The notation is:
#{end} |
The documents below demonstrate examples both in Word and Excel templates that iterate over all the Issue comments.
...
Iterating Fix Versions of an Issue
You can iterate over all fix versions that the Issue belongs to.
The notation is:
Project Versions Fields | Description |
---|---|
Name | The version name |
Description | The version description |
Start date | Starting date of the version |
Release date | Release date of the version |
Archived | Boolean that indicates if the version is archived or not |
Released | Boolean that indicates if the version is released or not |
Code Block | ||||
---|---|---|---|---|
| ||||
#{for projectVersionsFixVersions} ${ProjectVersionsFixVersions[n].Name} ${ProjectVersionsFixVersions[n].Description} ${dateformat(“dd-MM-yyyy”):ProjectVersionsFixVersions[n].Start date} ${dateformat(“dd-MM-yyyy”):ProjectVersionsFixVersions[n].Release date} ${ProjectVersionsFixVersions[n].Archived} ${ProjectVersionsFixVersions[n].Released} #{end} or #{for <VariableName>=ProjectVersionsCountFixVersionsCount} Content and Project Versions Issue Mappings. Example: ${ProjectVersionsFixVersions[VariableName].Field} #{end} |
The documents below demonstrate examples both in Word and Excel template templates that iterates iterate over all the issue project Issue fix versions.
Iterations_ProjectVersions Iterating_Issue_FixVersions.docx
Iterations_ProjectVersions
Iterating_Issue_FixVersions.xlsx
...
Iterating Affected Versions of an Issue
...
You can iterate over all affected versions that the Issue belongs to.
The notation is:
Versions Fields | Description |
---|---|
Name | The version name |
Description | The version description |
Start date | Starting date of the version |
Release date | Release date of the version |
Archived | Boolean that indicates if the version is archived or not |
Released | Boolean that indicates if the version is released or not |
Because it is not known in advance how many linked issues exist for an issue, you can iterate a section over all the linked issues of an issue. This allows you to create a table that dynamically grows according to the number of existing linked issues. The notation is:
Links Fields | Description |
---|---|
LinkType | The type of the link |
Key | The key of the linked issue |
Summary | The summary of the linked issue |
URL | The URL of the link |
Code Block | ||||
---|---|---|---|---|
| ||||
#{for linksAffectedVersions} ${LinksAffectedVersions[n].LinkTypeName} ${LinksAffectedVersions[n].KeyDescription} ${dateformat(“dd-MM-yyyy”):AffectedVersions[n].Start ${Linksdate} ${dateformat(“dd-MM-yyyy”):AffectedVersions[n].Release date} ${AffectedVersions[n].SummaryArchived} ${LinksAffectedVersions[n].URLReleased} #{end} or #{for <VariableName>=LinksCountAffectedVersionsCount} Content and LinkedVersions Issue Mappings. Example: ${LinksAffectedVersions[VariableName].Field} #{end} |
The documents below demonstrate examples both in Word and Excel template templates that iterates iterate over all the issue linksIssue-affected versions.
Iterations_Links Iterating_Issue_AffectedVersions.docx
Iterations_Links
Iterating_Issue_AffectedVersions.xlsx
...
Iterating
...
Because it is not known in advance how many subtasks exist for an issue, you can iterate a section over all the subtasks of an issue. This allows you to create a table that dynamically grows according to the number of existing subtasks. The notation is:
Project Versions
You can iterate over all project versions that the Issue belongs to.
The notation is:
Project Versions Fields | Description |
---|---|
Name | The version name |
Description | The version description |
Start date | Starting date of the version |
Release date | Release date of the version |
Archived | Boolean that indicates if the version is archived or not |
Released | Boolean that indicates if the version is released or not |
Subtasks Fields | Description |
Key | The key of the subtasks |
Summary | The summary of the subtasks |
AssigneeUserDisplayName | The assignee user of the subtasks
Code Block | ||||
---|---|---|---|---|
| ||||
#{for subtasksprojectVersions} ${ProjectVersions[n].Name} ${SubtasksProjectVersions[n].KeyDescription} ${dateformat(“dd-MM-yyyy”):ProjectVersions[n].Start ${Subtasksdate} ${dateformat(“dd-MM-yyyy”):ProjectVersions[n].Release date} ${ProjectVersions[n].SummaryArchived} ${SubtasksProjectVersions[n].AssigneeUserDisplayNameReleased} #{end} or #{for <VariableName>=SubtasksCountProjectVersionsCount} Content and Project IssueVersions Mappings. Example: ${SubtasksProjectVersions[VariableName].Field} #{end} |
The documents below demonstrate examples both in Word and Excel template templates that iterates iterate over all the issue subtasksIssue project versions.
Iterations_SubtasksProjectVersions.docx
Iterations_SubtasksProjectVersions.docxxlsx
...
Iterating
...
Issue Links
All fields listed here are available on IssuesInEpic[n] because they represent an issue.
Because it is not known in advance how many issues linked Issues exist for an epicissue, you can iterate a section over all the issues linked Issues of an epic issueIssue. This allows you to create a table that dynamically grows according to the number of existing issueslinked Issues.
The notation is:
Links Fields | Description |
---|---|
LinkType | The type of the link |
Key | The key to the linked Issue |
Summary | The summary of the linked Issue |
URL | The URL of the link |
Code Block | ||||
---|---|---|---|---|
| ||||
Code Block | ||||
| ||||
#{for IssuesInEpiclinks} ${IssuesInEpicLinks[n].KeyLinkType} ${IssuesInEpicLinks[n].SummaryKey} ${IssuesInEpicLinks[n].DescriptionSummary} ${IssuesInEpicLinks[n].Epic Link.KeyURL} #{end} or #{for <VariableName>=IssuesInEpicCountLinksCount} Content and Linked Issue Mappings. Example: ${IssuesInEpicLinks[VariableName].Field} #{end} |
The documents below demonstrate examples both in Word and Excel template templates that iterates iterate over all the issues in epicIssue links.
Iterating_Issues_In_Epic Iterations_Links.docx
Iterating_Issues_In_Epic
...
Iterating
...
Issue Subtasks
Because it is not known in advance how many subtasks exist for an Issue, you can iterate a section over all the subtasks of an Issue. This allows you to create a table that dynamically grows according to the number of existing subtasks.
You can iterate over all project components. The notation is:
Subtasks Fields | Description |
---|---|
Key | The key to the subtasks |
Summary | The summary of the subtasks |
AssigneeUserDisplayName | The assignee user of the subtasks |
Code Block | ||||
---|---|---|---|---|
| ||||
Code Block | ||||
| ||||
#{for ProjectComponentssubtasks} ${ProjectComponentsSubtasks[n].NameKey} ${ProjectComponentsSubtasks[n].DescriptionSummary} ${fullname:ProjectComponentsSubtasks[n].LeadAssigneeUserDisplayName} ${ProjectComponents[n].Id} ${ProjectComponents[n].ProjectId#{end} or #{for <VariableName>=SubtasksCount} ${ProjectComponents[n].AssigneeType} #{end} #{for <VariableName>=ProjectComponentsCount} Content and ComponentsContent and Issue Mappings. Example: ${ProjectComponentsSubtasks[VariableName].Field} #{end} |
The documents below demonstrate examples both in Word and Excel template templates that iterates iterate over all the project componentsIssue subtasks.
Iterating_Issue_ProjectComponents Iterations_Subtasks.docx
Iterating_Issue_ProjectComponents.xlsx
Applying filters to Iterations
If you want to take the previous iterations over comments, subtasks, and issue links to another level of control, you can use a JavaScript filter to define over which issues the iteration will be made. This can be useful in the following scenarios:
- Iterating over linked issues that are only of a specific issue type
- Iterating over subtasks of a specific issue type
- Iterating over linked issues with a specific priority
- Iterating over comments created by a specific user
...
Iterating Issues In Epic
All fields listed here are available on IssuesInEpic[n]
because they represent an Issue.
Because it is not known in advance how many Issues exist for an epic, you can iterate a section over all the Issues of an epic Issue. This allows you to create a table that dynamically grows according to the number of existing Issues.
The notation The notation for applying filters to the iterations is:
Code Block | ||||||
---|---|---|---|---|---|---|
| ||||||
#{for IssuesInEpic}
${IssuesInEpic[n].Key}
${IssuesInEpic[n].Summary}
${IssuesInEpic[n].Description}
${IssuesInEpic[n].Epic Link.Key}
#{end}
or
#{for <VariableName>=IssuesInEpicCount}
Content and Issue Mappings. Example: ${IssuesInEpic[VariableName].Field}
#{end} |
The documents below demonstrate examples both in Word and Excel templates that iterate over the Issues in epic.
...
Iterating Project Components
You can iterate over all project components.
The notation is:
Code Block | ||||
---|---|---|---|---|
| ||||
#{for ProjectComponents} ${ProjectComponents[n].Name} ${ProjectComponents[n].Description} ${fullname:ProjectComponents[n].Lead} ${ProjectComponents[n].Id} ${ProjectComponents[n].ProjectId} ${ProjectComponents[n].AssigneeType} #{end} #{for <VariableName>=<LinksCount|SubtasksCount|CommentsCount|WorklogsCount>|filter=%{<Javascript>}}ProjectComponentsCount} Content hereand Components Mappings. Example: ${ProjectComponents[VariableName].Field} #{end} |
- VariableName is the name of the variable to use as the iteration index.
LinksCount|SubtasksCount|CommentsCount indicates over which type of entities you want to iterate.
- Filter indicates the filter to be applied in the iteration.
Notice that as the filter is evaluated as a JavaScript expression, which provides flexibility in the definition of the conditions. You can use and (&&), or (||) and other logical operators supported by the JavaScript language.
It is also possible to format fields inside iteration filters.
The documents below demonstrate examples of a templates that iterate over issue links and comments with filters being applied.
Links Bugs with High Priority:
Nested Iterations:
Links_with_nested_Iterations.docx
Links_with_nested_Iterations.xlsx
For a working example of this functionality, check the template Sample Iterations in the Template Store.
Iterating in the same line of the document
You can also possible to iterate values in the same line of the document. This can be useful if you want to display a list of Subtasks on Linked Issues in the same line, separated by commas or spaces.
Code Block | ||||
---|---|---|---|---|
| ||||
Users that added comments to this issue: #{for comments}${Comments[n].Author} #{end}
Subtasks of this issue: #{for j=SubtasksCount}${Subtasks[j].Key};#{end}
Linked issues this issue duplicates: #{for j=LinksCount|filter=%{'${Links[j].LinkType}'.equals('duplicates')}}${Links[j].Key} #{end} |
...
The documents below demonstrate examples both in Word and Excel templates that iterate over the project components.
Iterating_Issue_ProjectComponents.docx
Iterating_Issue_ProjectComponents.xlsx
...
Applying Filters to Iterations
If you want to take the previous iterations over comments, subtasks, and Issue links to another level of control, you can use a JavaScript filter to define over which Issues the iteration will be made.
This can be useful in the following scenarios:
- Iterating over linked Issues that are only of a specific Issue type.
- Iterating over subtasks of a specific Issue type.
- Iterating over linked Issues with a specific priority.
- Iterating over comments created by a specific user.
The notation for applying filters to the iterations is:
Code Block | ||||
---|---|---|---|---|
| ||||
#{for <VariableName>=<LinksCount|SubtasksCount|CommentsCount|WorklogsCount>|filter=%{<Javascript>}}
Content here
#{end} |
- VariableName is the name of the variable to use as the iteration index.
LinksCount|SubtasksCount|CommentsCount indicates over which type of entities you want to iterate.
- Filter indicates the filter to be applied in the iteration.
Info |
---|
The filter is evaluated as a JavaScript expression, which provides flexibility in defining the conditions. You can use |
It is also possible to format fields inside iteration filters.
The documents below demonstrate examples of templates that iterate over Issue links and comments with filters being applied.
Links Bugs with High Priority:
Nested Iterations:
Links_with_nested_Iterations.docx
Links_with_nested_Iterations.xlsx
For a working example of this functionality, check the template Sample Iterations in the Template Store.
...
Iterating in the Same Line of the Document
You can also iterate values in the same cell in an Excel line of the document. You can achieve this by simply making your Iteration inside the same cell.You can use all the Iterations that you are used to and construct them in the exact same way, the difference being that you only use one cell to do them.This can be useful if you want to display a list of subtasks on linked Issues in the same line, separated by commas or spaces.
Code Block | ||||
---|---|---|---|---|
| ||||
Issue iteration as a demonstration.
Copy this iteration below and paste it into a cell.
&{for issues} ${Key} &{end} |
Iterating with the BREAK or CONTINUE statement
You can iterate anything, set up a Conditional expression and then utilize the BREAK and CONTINUE statements.
The way to do this is by doing a normal Conditional expression and using the mapping #{break} or #{continue} inside it.
Users that added comments to this issue: #{for comments}${Comments[n].Author} #{end}
Subtasks of this issue: #{for j=SubtasksCount}${Subtasks[j].Key};#{end}
Linked issues this issue duplicates: #{for j=LinksCount|filter=%{'${Links[j].LinkType}'.equals('duplicates')}}${Links[j].Key} #{end} |
...
Iterating in the Same Cell in an Excel Document
You can also iterate values in the same cell in an Excel document. You can achieve this by simply making your Iteration inside the same cell.
You can use all the Iterations that you are used to and construct them in the exact same way, the difference being that you only use one cell to do them.
Code Block | ||||
---|---|---|---|---|
| ||||
Issue iteration as a demonstration.
Copy this iteration below and paste it into a cell.
&{for issues} ${Key} &{end} |
...
Iterating with the BREAK or CONTINUE Statements
You can iterate anything, set up a Conditional expression, and then utilize the BREAK and CONTINUE statements.
The way to do this is by doing a normal Conditional expression and using the mapping #{break}
or #{continue}
inside it.
Code Block | ||||
---|---|---|---|---|
| ||||
Imagine that you have a Jira Issue that contains these comments:
- Hello
- World
- Greetings
- Hi
For the Break functionality, lets say that you want to stop the iteration if the current comment is "World". Here is the template for that:
#{for comments}
Current Comment: ${Comments[n].Body}
#{if (%{'${Comments[n].Body}'.equals('World')})}
#{break}
#{end}
Current Comment Author: ${Comments[n].Author}
#{end}
| ||||
Code Block | ||||
| ||||
Imagine that you have a Jira Issue that contains these comments:
- Hello
- World
- Greetings
- Hi
For the Break functionality, lets say that you want to stop the iteration if the current comment is "World". Here is the template for that:
#{for comments}
Current Comment: ${Comments[n].Body}
#{if (%{'${Comments[n].Body}'.equals('World')})}
#{break}
#{end}
Current Comment Author: ${Comments[n].Author}
#{end}
In this case, Xporter for Jira will print the comment "Hello" and it´s author. Next it will print the comment Body "World" but since the Conditional expression is true, it will stop the iteration all together and not print anything else.
Note: Anything after the #{break} mapping will not be printed in the exported document.
For the Continue functionality, lets say that you want to skip to the next iteration if the current comment is "World", bypassing the Author mapping for this iteration. Here is the template for that:
#{for comments}
Current Comment: ${Comments[n].Body}
#{if (%{'${Comments[n].Body}'.equals('World')})}
#{continue}
#{end}
Current Comment Author: ${Comments[n].Author}
#{end}
In this case, Xporter for Jira will print the comment "Hello" and it´s author. Next, it will print the comment Body "World" but since the Conditional expression is true, it will continue to the next iteration, not printing the Author of the "World" comment. |
...
Sorting
...
Iterations
Imagine that you have an iteration and want to sort it by any field that it can export normally.
This will be the header for such an iteration:
#{for comments|sortby=<Iteration mapping>} |
...
Info |
---|
The mapping after the |
...
|
...
must be equal to the supported mappings for each Iteration. |
Example:
Code Block | ||||
---|---|---|---|---|
| ||||
This iteration will be sorted by the Body of all the comments in the issue. #{for comments|sortby=Body} ${Comments[n].Author} ${Comments[n].Body} #{end} |
Sort By Bulk
...
Export
The sortby
can also be used to sort a &{for issues}
iteration on a Bulk Export.
...
Info | ||
---|---|---|
| ||
asc |
Expand | ||
---|---|---|
| ||
If you have questions or technical issues, please contact the Support team via the Customer Portal (Jira service management) or send us a message using the in-app chat. |