| Excerpt | ||
|---|---|---|
| ||
All provided Worklog Reports share some common concepts :... Aggregation, Hierarchie and Flat views |
| Easy Heading Macro |
|---|
Overview
Worklog Reports are all based on the same mechanism of aggregation. You will have to defined :
- the Report Type (List of Aggregation Criteria )
- the Criteria to use to filter Worklogs
Note that filtering will be applied only the filter Criteria is also an Aggregation Criteria - and which view to use
How worklogs are displayed
Different views are predefined :
- hierarchicView : Providing a Hierarchical display of aggregated data with expand and collapse features.
- flatView : Providing a classical display.
- excelView : Similar as flatView but without graphical rendering, used to export to Excel (undecorated HTML file).
Using Flat Views, the reports may display Issues with Sub-Tasks.
In such cases, the default behavior of the Flat View is to display the values associated to leaf of the aggregation tree, assuming that each parent node is just a calculation of leaf's values.
But, the both (Issues and Sub-Tasks) are able to have logged Work, and then the value displayed in Flat View is only the Sub-Task's Spent Time.
To avoid to display only the Sub-Task's Spent Time and be able to see Issue's Spent Time, a new parameter has been introduced in Reports : the Flattened Level (let me know if you find a best term !).
The Flattened Level expressed the depth of node to flat when displaying the Flat View.
By default, all nodes are flattened. For example, if your report provides an aggregation based on :
In such cases, the default behavior of the Flat View is to display the values associated to leaf of the aggregation tree, assuming that each parent node is just a calculation of leaf's values.
But, the both (Issues and Sub-Tasks) are able to have logged Work, and then the value displayed in Flat View is only the Sub-Task's Spent Time.
To avoid to display only the Sub-Task's Spent Time and be able to see Issue's Spent Time, a new parameter has been introduced in Reports : the Flattened Level (let me know if you find a best term !).
The Flattened Level expressed the depth of node to flat when displaying the Flat View.
By default, all nodes are flattened. For example, if your report provides an aggregation based on :
- Category
- Project
- Issue
and the displayed Issues have sub-task, you will be able to force the view to flat node only on the 3 first nodes.
Hopping that this explanation is comprehensive.
How Worklogs are filtered
Each report is built with a filtered list of Worklogs.
The filter is possible with below criteria.
| Criteria | Type | Description |
|---|---|---|
| Start Date | Absolute or Relative Date | Filtered Worklog have to be equal or after this date (1) |
| End Date | Absolute or Relative Date | Filtered Worklog have to be equal or before this date (1) |
| Category | Integer | Project Category Id. to use in filtering (2) |
| Project | Integer | Project Id. to use in filtering (2) |
| Developer | User or Group Name | Developer (Worker or author) having entered the Worklog (2)(3) |
- (1) Date Criteria support Relative Dates.
- (2) At least one of this criteria have to be selected. Selected values have to be valid for Category and Project.
- (3) If a Group is specified, the filter will take in account each Group's members.
| Warning |
|---|
Since Minyaa 3.3.2, the Worklog are now also filtered depending on permissions
|
Relative Date Operations
| Include Page | ||||
|---|---|---|---|---|
|
Which Unit are available
Most of report may be configured to change how the delay are expressed.
Different Units are proposed ...
| The available formats with sample rendering for 150h logged with 8h per day and 5 days per week.
|
How Worklogs are aggregated
All provided reports are based on the same aggregation mechanism.
- Each report performs its aggregation depending on the passed Report Type (URL parameter reportId ).
- The Report Type may be defined by different ways :
- Predefined, depending on each report and selectable during the Report Configuration,
- Built using a sequence of Aggregation Criteria
- Predefined, depending on each report and selectable during the Report Configuration,
- .
Available Aggregation Criteria are proposed in
- .
- the Workload Report
It is also possible to define
- - Issue report,
The resulting URL of your report will looks like reportElementKey1=CA&reportElementKey2=PR&reportElementKey3=IS_R&reportElementKey4=IS_CQ&reportElementKey5=CA&reportElementKey6=CA.
The reportElementKey5 and reportElementKey6 will be ignored, since CA criteria is already specified in reportElementKey1. - By using the Report Type (URL parameter reportId ) with as value the expected Aggregation Criteria coma separated.
For previous sample will be reportId=CA,PR,IS_R,IS_CQ
Note that, when selecting a new combination of Aggregation criteria, the resulting combination will be added a new predefined Report Types for others reports. - The Administrator can also define/restrict default combination of aggregation (
- - Issue report,
- See Workload Reports in Minyaa Time Settings ).
Which Aggregation Criteria are available
Minyaa provides different Aggregation Criteria (or ReportElement) for most of fields ...
For Systems Fields
| Code | Report Element Description |
|---|---|
| CA | Issue's Category |
| PR | Issue's Project |
| AS | Issue's Assignee |
| RS | Worklog's Author (Human Resource, Worker) |
| IS | Any Issue linked to the Worklog |
| IS_TS | Issue's Time Spent |
| IS_TE | Issue's Time Estimate |
| IS_OE | Issue's Time Original Estimate |
| IS_R | Issue's Reporter |
| IS_C x | Create Date Supported code are :
|
| IS_U x | Update Date Supported code are :
|
| IS_D x | Due Date Supported code are :
|
IS_R x (Since xxxx.1.17) | Resolution Date Supported code are :
|
| ST, STo | Sub-Task linked to the Worklog |
| PIS | Only Parent Issue linked to the Worklog |
| CP | Issue's Component |
| IV | Impacted Version |
| FV | Fix Version |
| IT | Issue's Type |
| PT | Issue's Priority |
| RL | Issue's Resolution |
| W x | Worklog Details Supported code are :
|
For Custom Fields
You can the customfield Id as Criteria Code
| Code | Report Element Description |
|---|---|
| customfield_ 999999 | Any custom field identified by its Id |
Their rendering in Report depends on implemented Customfield Types
| Customfield Types |
|---|
| com.atlassian.jira.issue.customfields.impl.SelectCFType |
| com.atlassian.jira.issue.customfields.MultipleSettableCustomFieldType |
| com.atlassian.jira.issue.customfields.MultipleCustomFieldType |
| com.atlassian.jira.notification.type.UserCFNotificationTypeAware |
| com.atlassian.jira.issue.customfields.impl.ExternalCFType |
| com.atlassian.jira.issue.customfields.impl.DateCFType |
| com.atlassian.jira.issue.customfields.impl.DateTimeCFType |
| com.atlassian.jira.issue.customfields.impl.AbstractMultiCFType |
| com.atlassian.jira.issue.customfields.impl.AbstractSingleFieldType |
| For any other are toString() is assumed |
How to restrict available Combination of Aggregation Criteria
As Administrator, you can limit or extend the default combination of Aggregation Criteria:
- Go to Manage Settings in Alkaes Setting section page,
- Select Settings Tabs for WorkloadReports ,
- You will be able to specify the Aggregation Criteria that will used (or extend existing) ...
