[[4]]Atlassian Plugin [[4]]

[[5]]Current Logged user[[5]]

[[6]]Project Identification number[[6]]

[[7]] Context defined in Portlet Configuration

[[7]]

Congratulations …

You have successfully installed Minyaa and want discover how Minyaa Reports can response to your needs …

From your JIRA Project View, 6 Minyaa reports are available :

• Workload Report (Issue Type)
• Workload Report (Project)
• Workload Report on Period
• Workload Report (Issue)
• Workload Report (Worklog Type)
• Stats. on Transition

Excepted the last one, all the 5 other reports are based on the same mechanism.

The report is generated using the same rules :

1. Search of all worklogs depending on Filter Criteria
2. Aggregation of found Worklogs following Aggregation criteria
3. Display of the aggregation following some other criteria

What are supported Aggregation Criteria ?

On a fresh installed Minyaa, the supported Aggregation Criteria are only the Issue attributes (Project Category, Project, Assignee, Due Date, …).

If you want to use Custom Fields, you will have to go to Minyaa Time Settings and enable the Allow report on CustomFields property.

Also, all Custom Fields will be available as Aggregation Criteria.

Note that some Custom Field (not provided by JIRA or Minyaa) may be unsupported by Minyaa Reports. To avoid to use them, you can enable the Allow report on only supported CustomField Type.

Using the default Report Configuration page, only the Workload Report (Issue) allows you to build your Aggregation Criteria selection.

The other reports provide a predefined list of combination … The most classical.

What are supported Filter Criteria ?

With current release, the supported Filter Criteria are only :

• Start and End Date of the worklog
• Project Category
• Project
• Worklog Author

Issue Filters are not usable for the moment, because the report requests directly the Worklogs and not the issues (It should be enhanced in future releases). Issue attributes are only resolved during the aggregation of Worklogs.

For design reasons, when you specify a value for one of Filter Criteria, it will be used for requesting Worklogs only if you define it also as Aggregation Criteria.
If it is not done, the Filter Criteria will be ignored !

How to have different Combinations for Aggregation Criteria ?

Minya Reports are not limited in terms of level of aggreation. You define a report with a large number of Aggregation Criteria. The only limits are :

1. The list of Fields and Customfield supported and available in your model,
2. The width of your screen,
3. And the sense you will be able to find to complex aggregation.

To have new combination of criteria, you will have the following solutions :

1. In Workload Report (Issue) , you can select field by field up to 6 different fields.
2. As soon as, you have used a new combination in Workload Report (Issue) , the combination is memorized and added as a valid combination for others reports. Note the new combinations are not persisted in database, and are only available until the next JIRA restart.
3. You can build manually the wanted combination directly by modifying the URL request (See below …)
4. You can build your own plugin of predefined report request, using web-item modules.

How to define Minyaa Reports by changing the URL requests ?

In Workload Report (Issue), Aggregation Criteria are defined field by field and passed to the Report through the “reportElementKeyN” request parameter, where N is the sequence number.

In other Workload Reports, this sequence of parameters is replaced by only one request parameter : reportId, where the value represents the combination of criteria.

If you change directly this value, it will create new combination … Pick in the list of possible values and define your aggregation :

1. PR,RS,IS for Project, Resource, Issue
2. PR, RSs,IS for Project, Group of Resources, Issue
3. RS,IS,WT for Resources, Issue, Worklog Type
4. WQ,WW,IS for Worked Date in Quarter, Worked Date in Week, Issue
5. PR,customfield_10010,Issue for Project, One of Custom Field, Issue
6. etc.

This way to do is not aesthetic, but it allows users to create quickly the correct report following their needs. When the report configuration is identified, just memorized the request as short link in your Browser.

How to re-use Report Definition ?

The short link is a quick solution, but it is not easy to reuse in the time.
To resolve the re-usability of report definition, Minyaa supports for its report the Relative Dates ^[2] …

For Start Date and End Date , instead of using Absolute Dates ^[1]  in your reports, privilege the Relative Dates ^[2] . Most of time, you want to have a view of time spent on issues for always the same time-line : Last week, Last Month, …

A Relative Dates contains a Basis and a Date Operand. The Basis may be :

• NOW for Current Date Time
• BOM for Begin Of Month
• EOM for End Of Month
• etc,

and the Date Operand may be :

• +1D for Plus 1 day (Attention, the + has to be replaced in the URL by %2B)
• -2W for Minus 2 weeks

If the Basis is not defined, NOW {{3}} is assumed in case of Start Date, and Start Date‘s value is assumed as Basis for End Date. Assumed default values are Start Date=BOM and End Date=+1M (Then EOM).

The request parameters of the URL can be as follow : reportId=PR,RS,IS&startDate=BOY&endDate=%2B1m&categoryId=&projectId=&author=&unitType=2&showKey=yes&showSummary=yes&selectedProjectId=10000&reportKey=jira.plugin.minyaa.time%3Aworkload-issue

How to share Report Definitions ?

To share your report definition with someone, you can give him the request … Why not ! You can explain him how to adapt it for changing the filtered User, Project, …

To share it with everybody in your team/department/company … No !
Use the Fragment Gagdet with a in-house plugin{{4}} where your predefined report are stored.

To do that, you will have to :

1. Identify your Report Definition as Request URL (See just above section)
2. Adapt this request to be dynamic :
   1. By using Relative Dates ^[2],
   2. By changing Project and User references by Context key
      ($user {{5}}, $helper.project.id {{6}})
3. Build a small in-house JIRA plugin where you will define a set of Web-Item modules …
4. Deploy the built plugin in you JIRA instance

After, anyone will be able to add a Fragment Gadget in his Dashboard, specifying the context {{7}} to use (User or Project), and then benefit of your predefined reports.

Note that this solution has been introduced for Minyaa reports, but can be generalized to any JIRA reports !

How to create your Predefined Report Plugin will be done to explain step by step in another

[[6]]Project Identification number[[6]]

[[7]] Context defined in Portlet Configuration

[[7]]

Congratulations …

You have successfully installed Minyaa and want discover how Minyaa Reports can response to your needs …

From your JIRA Project View, 6 Minyaa reports are available :

• Workload Report (Issue Type)
• Workload Report (Project)
• Workload Report on Period
• Workload Report (Issue)
• Workload Report (Worklog Type)
• Stats. on Transition

Excepted the last one, all the 5 other reports are based on the same mechanism.

The report is generated using the same rules :

1. Search of all worklogs depending on Filter Criteria
2. Aggregation of found Worklogs following Aggregation criteria
3. Display of the aggregation following some other criteria

What are supported Aggregation Criteria ?

On a fresh installed Minyaa, the supported Aggregation Criteria are only the Issue attributes (Project Category, Project, Assignee, Due Date, …).

If you want to use Custom Fields, you will have to go to Minyaa Time Settings and enable the Allow report on CustomFields property.

Also, all Custom Fields will be available as Aggregation Criteria.

Note that some Custom Field (not provided by JIRA or Minyaa) may be unsupported by Minyaa Reports. To avoid to use them, you can enable the Allow report on only supported CustomField Type.

Using the default Report Configuration page, only the Workload Report (Issue) allows you to build your Aggregation Criteria selection.

The other reports provide a predefined list of combination … The most classical.

What are supported Filter Criteria ?

With current release, the supported Filter Criteria are only :

• Start and End Date of the worklog
• Project Category
• Project
• Worklog Author

Issue Filters are not usable for the moment, because the report requests directly the Worklogs and not the issues (It should be enhanced in future releases). Issue attributes are only resolved during the aggregation of Worklogs.

For design reasons, when you specify a value for one of Filter Criteria, it will be used for requesting Worklogs only if you define it also as Aggregation Criteria.
If it is not done, the Filter Criteria will be ignored !

How to have different Combinations for Aggregation Criteria ?

Minya Reports are not limited in terms of level of aggreation. You define a report with a large number of Aggregation Criteria. The only limits are :

1. The list of Fields and Customfield supported and available in your model,
2. The width of your screen,
3. And the sense you will be able to find to complex aggregation.

To have new combination of criteria, you will have the following solutions :

1. In Workload Report (Issue) , you can select field by field up to 6 different fields.
2. As soon as, you have used a new combination in Workload Report (Issue) , the combination is memorized and added as a valid combination for others reports. Note the new combinations are not persisted in database, and are only available until the next JIRA restart.
3. You can build manually the wanted combination directly by modifying the URL request (See below …)
4. You can build your own plugin of predefined report request, using web-item modules.

How to define Minyaa Reports by changing the URL requests ?

In Workload Report (Issue), Aggregation Criteria are defined field by field and passed to the Report through the “reportElementKeyN” request parameter, where N is the sequence number.

In other Workload Reports, this sequence of parameters is replaced by only one request parameter : reportId, where the value represents the combination of criteria.

If you change directly this value, it will create new combination … Pick in the list of possible values and define your aggregation :

1. PR,RS,IS for Project, Resource, Issue
2. PR, RSs,IS for Project, Group of Resources, Issue
3. RS,IS,WT for Resources, Issue, Worklog Type
4. WQ,WW,IS for Worked Date in Quarter, Worked Date in Week, Issue
5. PR,customfield_10010,Issue for Project, One of Custom Field, Issue
6. etc.

This way to do is not aesthetic, but it allows users to create quickly the correct report following their needs. When the report configuration is identified, just memorized the request as short link in your Browser.

How to re-use Report Definition ?

The short link is a quick solution, but it is not easy to reuse in the time.
To resolve the re-usability of report definition, Minyaa supports for its report the Relative Dates ^[2] …

For Start Date and End Date , instead of using Absolute Dates ^[1]  in your reports, privilege the Relative Dates ^[2] . Most of time, you want to have a view of time spent on issues for always the same time-line : Last week, Last Month, …

A Relative Dates contains a Basis and a Date Operand. The Basis may be :

• NOW for Current Date Time
• BOM for Begin Of Month
• EOM for End Of Month
• etc,

and the Date Operand may be :

• +1D for Plus 1 day (Attention, the + has to be replaced in the URL by %2B)
• -2W for Minus 2 weeks

If the Basis is not defined, NOW ^[3] is assumed in case of Start Date, and Start Date‘s value is assumed as Basis for End Date. Assumed default values are Start Date=BOM and End Date=+1M (Then EOM).

The request parameters of the URL can be as follow : reportId=PR,RS,IS&startDate=BOY&endDate=%2B1m&categoryId=&projectId=&author=&unitType=2&showKey=yes&showSummary=yes&selectedProjectId=10000&reportKey=jira.plugin.minyaa.time%3Aworkload-issue

How to share Report Definitions ?

To share your report definition with someone, you can give him the request … Why not ! You can explain him how to adapt it for changing the filtered User, Project, …

To share it with everybody in your team/department/company … No !
Use the Fragment Gagdet with a in-house plugin^[4] where your predefined report are stored.

To do that, you will have to :

1. Identify your Report Definition as Request URL (See just above section)
2. Adapt this request to be dynamic :
   1. By using Relative Dates ^[2],
   2. By changing Project and User references by Context key
      ($user {{5}}, $helper.project.id {{6}})
3. Build a small in-house JIRA plugin where you will define a set of Web-Item modules …
4. Deploy the built plugin in you JIRA instance

After, anyone will be able to add a Fragment Gadget in his Dashboard, specifying the context {{7}} to use (User or Project), and then benefit of your predefined reports.

Note that this solution has been introduced for Minyaa reports, but can be generalized to any JIRA reports !

How to create your Predefined Report Plugin will be done to explain step by step in another