first and foremost: I searched the eazyBI community and also the web, but did not find a solution for my issue.
we have several components, which can be clustered in different groups by their prefix. So, we do have something like this as component names:
“group1 abcd”
“group1 efgh”
“group1 ijkl”
“group2 bcde”
“group2 fghi”
“group2 jklm”
and more groups and distinct second part of the component names.
What we want to achieve is to have a grouping available in Pages section of eazyBI, which allows us to count issues based on different measures (which, to my understanding, is the main focus of eazyBI in Jira).
To be very precise, here is what we are doing currently:
defined new calculated members in “Project” dimension, named after the groups (so we would have “group1” and “group2” calculated member with the example above) with the following codeAggregate( Filter( [Project].[Component].Members, [Project].CurrentMember.Name MATCHES '.*group1 .*' ))
these calculated members are made available in Pages section to be able to use the same diagram for each group
using “Issues history” predefined measure to get number of issues over time, and at the end splitting this up by transition status
this should give us a diagram (or table) showing the development of number of issues per status over a certain period of time
However, this does not work correctly. When selecting the “All Projects” member in the Pages section, it all works fine and we are getting correct issue counts. But if we are selecting the new calculated members in Pages section, we are getting way higher numbers, because not the number of issues is counted, but the number of component occurences.
Here is an example:
Issue 1234 has components “group1 abcd”, “group1 efgh” and “group2 bcde”.
This should only count as one issue, but in fact, in our diagrams (or tables) it shows up as 3, because obviously components are counted and not issues
You have understood everything correctly - with Issues created standard measures (and Issues history), eazyBI counts how many Components (or Labels, or other multi-value fields) are added to the issue. For standard measures, you can use the Distinct count measures.
Counting of history is a bit more complex and to see how many issues with at least one of selected components were in the past statuses, you can write a new calculated measure for Distinct Issues history measure:
NonZero(Count
(Filter(
Descendants([Issue].CurrentHierarchyMember, [Issue].[Issue]),
IIF([Time].CurrentHierarchyMember is [Time].CurrentHierarchy.DefaultMember,
1,
DateBeforePeriodEnd(
[Issue].CurrentHierarchyMember.Get('Created at'),
[Time].CurrentHierarchyMember)
AND
[Measures].[Issues history] > 0
))))
Unfortunately, I’m always running in an out of memory error, even when creating very easy and small queries.
E.g. taking only the new calculated measure in columns, and time in rows, nothing in pages. When not expanding the “All times” member, everything is fine. As soon as trying to expand the member, I’m running in the named out of memory error (eazyBI is currently granted 1,5GB of memory, we do have ~ 100.000 issues in the cube).
Anything that I can change? Some “pre-filtering” necessary, so number of issues is lower?
thanks, to understand those limits already helped. I have now created an account with < 3k issues and also increased the available JVM heap mem to 3GB.
This already allows me to get a weekly statistics of issue history, separated by relevant status (time in rows, Distinct Issues history and Transition Status in columns). In Transition Status dimension I used the bookmark feature to select relevant status and afterwards selected those bookmarks instead of the All Transition Statuses member.
However, creating a table (or diagram) for that still takes quite long to my understanding (~30s). Is there any way to get faster?
On top of that, using the filtering mechanism on components described in my first comment to the issue does not work at all. Having the Projects dimension in Pages and selecting the Projects member works out. But as soon as I introduce the calculated members described in comment 1 and trying to use them, I’m running into timeouts, even with extended timeout of 120s. Any thoughts on this?
Is my account still holding too much issues? Any options to reduce runtime by tweaking the calculated measure?
Good to hear that the suggestions have helped to move forward! Unfortunately, I would say that about 30sec for MDX calculations that include going through all issues (the Descendants() function) is expected. You could send the report definition to me (support@eazybi.com and please mention that we are discussing it in this thread) and I will check if there is some other tuning I can figure out. 3k issues are certainly not too much!
For the Component grouping - multi-select, especially if there are many components, can be time-consuming to calculate. As the next step, I would suggest considering creating a new dimension called ‘Component group’ and use that instead of aggregating components in Projects dimension. You could do this with JavaScript calculated fields. See also “Behind complex filters” presentation.
We’ll look into the calculations ourself and afterwards will decide about sending the report definition. Thank you very much for giving us the opportunity to do so!
Thanks also for the idea with the calculated fields. As we do have the JMCF plugin as well (which is one of the recommended ways to go as per https://docs.eazybi.com/eazybijira/data-import/custom-fields/javascript-calculated-custom-fields) I would be interested in whether there are any constraints we need to adhere to when creating such calculated fields with JMCF. Why am I asking? We already have several calculated fields in our Jira project, but a majority of them is not available for import in eazyBI.
Oh great, we should definitely dig deeper in the available documentation. I’m sorry for asking questions that - at least the majority of them - can be answered with RTM.
I extended our Jira instance with a custom field containing all component groups that the issue is affecting. This field contains a comma-separated string (e.g. “group1,group2”).
Afterwards, I updated the eazyBI advanced settings to make this field available as a dimension, and also tried to have eazyBI automatically giving me the values that are available, thinking that they would show up as individual members in that new dimension (“group1”,“group2”).
Here is what I added to the advanced settings:
[jira.customfield_11607]
data_type = “string”
dimension = true
multiple_values = true
split_by = “,”
Unfortunately, I do not get the individual members, but only the “All …” member with this. Did I understand the multiple_values parameter wrong?
The configuration looks correct and you have correctly understood what you should be getting.
Could you first please try to unselect the custom field and run the import without it and then select it for import again? Possibly there were some changes done to the field after it was first imported, but then it was not re-imported for all issues.
If that does not help, could you please send me a JSON of an issue that has a couple of component groups (JIRA_BASE_URL/rest/api/latest/issue/ISSUE-ID) as well as a screenshot of expanded new dimension and Issues created measure in Analyze tab. (You can send these directly to support@eazybi.com).