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 agregation 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 :
and the display 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.
Relative Date Operator
Date criteria may be filled with a relative Date format. The formay follows below codification :
Code | Value Description |
BOW | Begin Of Week |
EOW | End Of Week |
BOM | Begin Of Month |
EOM | End Of Month |
BOQ | Begin Of Quarter |
EOQ | End Of Quarter |
BOS | Begin Of Semester |
EOS | End Of Semester |
BOY | Begin Of Year |
EOY | End Of Year |
+1D | Day |
+1B | Business Day |
+1W | Week |
+1M | Month |
+1Q | Quarter |
+1S | Semester |
+1Y | Year |
The supported syntax allows for example :
- StartDate = -2W, EndDate = +3D
- StartDate = BOW-2W, EndDate = EOW
- StartDate = BOM-2W, EndDate = EOM
Future release should support some syntax like BOM(NOW-2w) for begin of Month relatively to today - 2 Weeks, and so ...
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.
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 (See Workload Report by Worklog Type)
Minyaa provides different
Aggregation Criteria (or
ReportElement) for most of fields :
Code | Report Element Description |
CA | Issue's Category |
PR | Issue's Project |
RS | Worklog's Author (Human Resource, Worker) |
IS | Any Issue linked to the Worklog |
ST | Only 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 |
Wx | Worked Periods
Supported code are :
- WD : by Day
- WW : by Week
- WM : by Month
- WQ : by Quarter
|
customfield_999999 | Any custom field identified by its Id |
Supported Customfield types are
Customfield Types | Samples |
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 | |