Page History
In this page, it's explained how to export a property when it has more than a single value such as:
Table of Contents |
---|
The Document Generator also provide way to handle data by filtering nad sorting data directly on the iteration definition
Table of Contents |
---|
...
Issue History
Changes to issues are registered in the Issue History, but it is not known in advance how many changes are going to be made. You can iterate a section over all the history entries of an issue. This allows you to create a table that dynamically grows according to the number of changes dene. The notation is:
...
Code Block | ||||
---|---|---|---|---|
| ||||
#{for historyEntries} ${fullname:HistoryEntries[n].Author} made changes ${dateformat("dd-MM-yyyy HH:mm:ss"):HistoryEntries[n].Created} #{for ch=HistoryEntries[n].ChangedItemsCount} Field Name: ${HistoryEntries[n].ChangedItems[ch].Field} Old Value: ${HistoryEntries[n].ChangedItems[ch].From} New Value: ${HistoryEntries[n].ChangedItems[ch].To} #{end} #{end} or #{for h=HistoryEntriesCount} ${fullname:HistoryEntries[h].Author} made changes ${dateformat("dd-MM-yyyy HH:mm:ss"):HistoryEntries[h].Created} #{for ch=HistoryEntries[h].ChangedItemsCount} Field Name: ${HistoryEntries[h].ChangedItems[ch].Field} Old Value: ${HistoryEntries[h].ChangedItems[ch].From} New Value: ${HistoryEntries[h].ChangedItems[ch].To} #{end} #{end} |
...
Issue
...
Links
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 |
---|---|
AppType | The application type of the link |
LinkType | The type of the link |
Info |
---|
We suggest that you use the html function to render the data because almost all content is HTML, e.g., ${html:ActivityEntries[n].Title} |
Below is an example of using the Activity iteration in a Word template:
or
Below is an example of using the Activity iteration in an Excel template:
or
Iterating Issue Links
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 |
---|---|
AppType | The application type of the link |
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 |
...
The image below demonstrates an example of an Excel template that iterates over linked issues.
or
...
Issue Comments
Because it is not known in advance how many comments exist for an issue, you can iterate a section over all the comments on an issue. This allows you to create a table that dynamically grows according to the number of existing comments. The notation is:
...
The image below demonstrates an example of a Word template that iterates over issue comments.
or
For a working example of this functionality, check the SampleIterations.docx template in the Template Store.
The image below demonstrates an example of an Excel template that iterates over issue comments.
or
Info | ||
---|---|---|
| ||
If you are using Jira Service Desk you can see more information about comments here. |
Issue Worklogs
Because it is not known in advance how many worklogs exist for an issue, you can iterate a section over all the worklogs of an issue. This allow you to create a table that dynamically grows according to the number of existing worklogs. The notation is:
...
For a working example of this functionality, check the SampleIterations.docx template in the Template Store.
The image below demonstrates an example of a template in Excel that iterates over issue work logs.
or
...
Issue
...
Sub-Tasks
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:
...
For an example of how to iterate the details of a subtask Parent issue, please check the Iterating JQL Queries area below.
...
Issue Components
Because it is not known in advance how many components exist for an issue, you can iterate a section over all the components of an issue. This allows you to create a table that dynamically grows according to the number of existing components. The notation is:
...
The image below demonstrates an example of an Excel template that iterates over issue components.
...
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:
...
The image below demonstrates an example of a Word template that iterates over status transitions.
or
The image below demonstrates an example of an Excel template that iterates over status transitions.
or
...
Issue Attached Images
Because it is not known in advance how many Images can exist for an issue (as an attachment), you can iterate a section over all the attached 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 images. The notation is:
...
The image below demonstrates an example of an Excel template that iterates over attached images.
or
...
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:
...
The image below demonstrates an example of a Word template that iterates over attachments.
or
The image below demonstrates an example of an Excel template that iterates over attachments.
or
...
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:
...
The image below demonstrates an example of an Excel template that iterates over labels.
or
...
Project Versions
...
You can iterate over all project versions to which the issue belong to. The notation is:
...
Info |
---|
You can also use a Filter Name or a Filter Id as a clause. For more info, read this. |
Iterating Issue Commits
Because it is not known in advance how many commits exist for an issue, you can iterate a section over all the commits of an issue. This allows you to create a table that dynamically grows according to the number of existing commits. The notation is:
...
The URL of the link
...
Message
...
Author
...
Code Block | ||||
---|---|---|---|---|
| ||||
#{for commits}
${Commits[n].Author}
${Commits[n].URL}
${Commits[n].Message}
${Commits[n].CreatedDateTime}
Here we have the FilesCount where we can get all the files associated with a commit.
#{for m=Commits[n].FilesCount}
${Commit[n].FilesCount[m].Path}
${Commit[n].FilesCount[m].URL}
${Commit[n].FilesCount[m].ChangeType}
#{end}
#{end}
or
#{for <VariableName>=CommitsCount}
Content and Issue Mappings. Example: ${Commits[VariableName].Field}
#{end} |
Iterating Issue Branches
Because it is not known in advance how many branches exist for an issue, you can iterate a section over all the branches of an issue. This allows you to create a table that dynamically grows according to the number of existing branches. The notation is:
Branches Fields | Description |
---|---|
URL | The URL of the Branch |
Name | The name of the Branch |
RepositoryName | The name of the repository |
RepositoryURL | The URL of the repository |
Code Block | ||||
---|---|---|---|---|
| ||||
#{for branches}
${Branches[n].URL}
${Branches[n].Name}
${Branches[n].RepositoryName}
${Branches[n].RepositoryURL}
#{end}
or
#{for <VariableName>=BranchesCount}
Content and Issue Mappings. Example: ${Branches[VariableName].Field}
#{end} |
Iterating Issue Pull Requests
As it is not known in advance how many pull requests exist for an issue, you can iterate a section over all the pull requests of an issue. This allows you to create a table that dynamically grows according to the number of existing pull requests. The notation is:
...
The URL of the Branch
...
RepositoryName
...
RepositoryURL
...
The URL of the repository
...
You can get information about reviewers from each pull request:
...
Code Block | ||||
---|---|---|---|---|
| ||||
#{for pullRequests}
${PullRequests[n].URL}
${PullRequests[n].Name}
${PullRequests[n].RepositoryName}
${PullRequests[n].RepositoryURL}
${PullRequests[n].CommentsCount} (This represents the number of comments in a pull request)
${PullRequests[n].Status}
${PullRequests[n].LastUpdated}
Here we have the PullRequestReviews where we can get all the reviewers for this pull request.
#{for m=PullRequests[n].PullRequestReviewers}
${PullRequests[n].PullRequestReviewers[m].Name}
${PullRequests[n].PullRequestReviewers[m].Approved}
#{end}
#{end}
or
#{for <VariableName>=PullRequestsCount}
Content and Issue Mappings. Example: ${PullRequests[VariableName].Field}
#{end} |
Iterating Issue Builds
Because it is not known in advance how many builds exist for an issue, you can iterate a section over all the builds of an issue. This allows you to create a table that dynamically grows according to the number of existing builds. The notation is:
...
Plans.Key
...
Plans.BuildNumber
...
Code Block | ||||
---|---|---|---|---|
| ||||
#{for builds}
${Builds[n].ProjectName}
${Builds[n].ProjectKey}
Here we have the each Build Plans where we can get all the individual plans for this project and the correspondent build in existence for this plan.
#{for m=Builds[n].Plans}
${Builds[n].Plans[m].Key}
${Builds[n].Plans[m].Name}
${Builds[n].Plans[m].BuildNumber}
${Builds[n].Plans[m].BuildKey}
${Builds[n].Plans[m].BuildDuration}
${Builds[n].Plans[m].BuildFinishedDate}
#{end}
#{end}
or
#{for <VariableName>=BuildsCount}
Content and Issue Mappings. Example: ${Builds[VariableName].Field}
#{end} |
Iterating Issue Reviews
Because it is not known in advance how many reviews exists for an issue, you can iterate a section over all the pull requests of an issue. This allows you to create a table that dynamically grows according to the number of existing reviews. The notation is:
...
The review ID, e.g., 1
...
The URL of the review
...
The review status
...
Code Block | ||||
---|---|---|---|---|
| ||||
#{for reviews} ${Reviews[n].Id} ${Reviews[n].URL} ${Reviews[n].Status} ${Reviews[n].Title} ${Reviews[n].Author} ${Reviews[n].Moderator} Here we have the Reviewers for each review where we can get all the individual reviewers for this review. #{for m=Reviews[n].Reviewers} ${Reviews[n].Reviewers[m].Username} ${Reviews[n].Reviewers[m].Completed} #{end} #{end} or #{for <VariableName>=ReviewsCount} Content and Issue Mappings. Example: ${Reviews[VariableName].Field} #{end} |
Applying filters to Iterations
...