New filter: Assignee'sGroup

[tainewoo]

Hi deecay,

PivotTable is a great plugin and it helps a lot when generating analysis data.
Is it possible to add a new filter Assignee'sGroup, which means the Group which the assignee is in (one user may belong to more than one group since nested group).
It would be great to analysis issues in different groups.

[tainewoo]

and maybe also the Author'sGroup

[deecay]

Hi,

Thanks for the idea. I haven't give it a thought yet, but I couldn't understand how a pivot table can be generated if user can belong to more than one group. Can you explain what you are aiming for, based on the group setup and its result pivot table?

Note: Please remember, issue pivot table has to have row total and col total to be equal to the total number of the issues. This means, whatever the intermediate dimensions are, there should not be any double counting of the issue.

[tainewoo]

Hi deecay,
Thank you for your reply.
Normally we need to know the project situation based on the issue counts vs groups, and maybe together with other filters such as priority and status etc.
I can have a simple description about it.
Case:
R&DGroup:
-Group1
--Group1SubGroupA
---Group1SubGroupA---UserI
---Group1SubGroupA---UserII
--Group1SubGroupB
...
-Group2
...

From the filter, I can use the Assignee'sGroup tab instead of Assignee tab, and the managers knows the architecture of the nested groups, so they can click on the triangle corner mark on it to select the filtered groups they want (the groups is a collection of all the groups comes from all Assignees, Pivot don't need to consider to much about it).
In this case, user can set the groups as Group1SubGroupA+Group1SubGroupB+Group1SubGroupC ..... , or Group1+Group2+Group3 ....
Then the chart will become a IssueCount vs Groups table.

Normally an Assignee will only belongs to one functional group within a same level, but if the Assignee belongs to multiple groups it means the issues belong to all the groups as well, it's ok, since the user defined their team architecture by that for maybe special purpose.

[tainewoo]

From Redmine's Issue Filter, we can find the filter as "Assignee'sGroup", maybe Pivot can use similar way to get the Assignee'sGroup and collect and map them to data structure for further use.

[tainewoo]

I didn't find the issue filter from Redmine for Author'sGroup but Redmine filter can use all sub properties of the main properties as filter, such as Assignee'sGroup, Assignee'sRole, and also the custom fields of them.

For the case of Author'sGroup, we can have the tables comapred between groups for how many issues created, and maybe together with other issue properties such as category/version or others.

[deecay]

Hi,

I think I understand what you want to achieve. But since Groups are not unique per issue, I don't think it will be appropriate to make it an attribute.

Let's say the total number of issues are 10. If UserA belongs to both GroupA and GroupB. If the y-axis are 'Group - User' and x-axis 'Created', what should we see?

		Date 12/25	Totals
GroupA	UserA	10	10
GroupB	UserA	10	10
Total	-	20	20

Here you can see that pivot table should show the breakdown of the 10 issues in question, but here we will see total of 20. So an attribute must always be exclusive. 'Created date', 'priority', 'Assigned To' and all other attributes are unique and exclusive from each issue's point of view. But since 'Assigned To' user can belong to multiple Groups, it's inappropriate to have Group as an attribute. Sure it will work in some cases, but in all other cases it will show the incorrect value.

[tainewoo]

Hi deecay,
Yes there will be such kind of limitation if the team architecure is defined like this, but normally in the normal team's view, only a user is special role in the group will be included by diffrerent groups, such as manages different groups. So if the issue is assigned to a manager who belongs to GroupA and GroupB, it means the issue may belongs to both groups, members of both groups can be the contributor of that issue.
And if users in this kind of team architecture, they will know how to define their query filter and chart filter, i think. Maybe we can just put some words to indicate, such as below:
Total: can be 2 kinds of sum in the sample case you described:
1, just sum the count of GroupAUserA and GroupAUserB, the "Total" doesn't have it's own query.
2. every count has it's own query statement, which is distinct collection of issues, and counts the distinct issues (by id), maybe we can call it Total(Distinct) or Count(Distinct).
3. even more, maybe we can have the number with two parts, first part is the count just current logic, the second part is the shared issue numbers, appended when the result includes shared issues. but this is too complicated.

[konpega]

Hi gentlemen;
Even in excel file this is really complex to show such kind information. @tainewoo If you think about the convinient example you will go through the wrong way, while programming anybody shall consider the bad case, as you know also nobody will deal or try to filter in thousands of data the correct case. They will deal only with the results. I agree @deecay to be able get te correct data, you should have one table like excel and total amount should be always the same. @tainewoo you are trying to add some filters. This time I think, at least I have solved some issues in access in this way, we need to create a table or query and we should use that table or query for the pivottable. In this case also you should be carefull, you should use this kind of generic data (like group) in the row just to see the distribution of real issue number which should and could be countable.

[tainewoo]

Hi @konpega and @deecay ,
Yes you are right about the data correctness.
I have the filter of "Assignee's Group" from Redmine Issue Filter already, also I implemented the "Author's Group" filter by adding plugin too, so if we can just get all the filters provided by Redmine Issue filters, and list them as the filter list for PivotTable for users, I think users will have there method to filter and get the correct data.
Such as, if users want to get the data of some First Level Groups, the can only get the FirstLevelGroups checked from PivotTable, if they want to get the data of some of the SecondLevelGroups they can also only get the related groups checked.
And if one user belongs to 2 different groups (same level), normally the user (normally the user is kind of management) will know the double counted problem, just let user to determine how to use by theirself. Or maybe we just indicate the potential risk warning from the PivotTable page.

[konpega]

If the people would be aware of it by a warning at this page, this sounds logical and usefull. But also it should be expressed the concern detailly. (ATTENTION : Due to the issues may be assigned to a group, assignee's values would be correct for evaluation one by one, but total of the assignee's values would not be equal to the total number issue. BE CAREFULL)

[tainewoo]

Hi @konpega， yes, and if any user only belongs to only one group the total number of issues would be correct, the total number can be incorrect only if there is user belongs to more than one group.
So if there is warning message left for users, this should be ok. And this feature would be very useful for management to check the issue status between groups.