Hi,
I am quite new to EazyBI so maybe my question would sound silly… anyway I need to move forward so I am trying to ask experts because I haven’t found any solution yet.
We have imported Jira issue data from jira server together with Tempo data. I am creating reports of logged work. I can handle exising dimensions of logged work but I fail to import custom dimensions.
In detail,
I need to create report which would aggregate logged work into custom user categories (eg. Internal user, External user) based on the relation of user and the userCategory.The relation is: each user who logged work belogs to one userCategory.
Another Dimension is Domain (Core Team, Feature Team)
Then I want to create report of logged work such as:
Report 1 UserCategory | Hous_spent
Internal | 200 hrs
External | 300 hrs
Report 2 Domain | Hous_spent
Core Team | 150 hrs
Feature Team | 350 hrs
I would import CSV such as:
User_ID; UserCategory;Domain
user_1; Internal;Core Team
user_2; Internal;Feature Team
user_3; External;Core Team
user_4; External;Feature Team
But I don’t know how to prepare such reports.
May I ask you for advice?
Thank you very much,
Jan
Hi janis,
We need this kind of hierarchy for time-spent data. When I follow your instruction as above, I added a new property, but I can’t use it like a hierarchy because the system forces me to use the same level or measure name, such as “user.” Is there any way to use this kind of hierarchy logged by data?
Multiple-level additional hierarchies are not supported currently, so there is no workaround for this use case, unfortunately. We have such a feature in our backlog, but I cannot estimate when it might be implemented.
I’d also like to add my vote for this feature request.
We currently add properties to users (Assignees, Reporters, etc) via SQL import, and use the eazyBI custom hierarchies in our reports.
In addition, it’d be great to be able to add properties from SQL import to Assignee Groups (and others). I realize these are multi-value fields that may be tough to map, however, maybe Users and Groups need to be treated differently and more centrally.
Following on this line of thinking, maybe it is worth providing a way to have access to all Jira users and groups in all cubes (with the possibility of overloading them with other properties), not just the ones that happen to have fact data in one cube, e.g. if a user is not assigned an issue in a cube, you cannot get their user data/properties via the Assignee dimension.