I’m trying to set up an EazyBI report but running into some problems with the configuration.
My goal is to monitor issues over a 2-month period, specifically looking at data for Mondays only. I already got the time aspect working by adding a Time member in the Pages section and drilling down to individual days.
The tricky part is this: I need to show all issues that had “High” priority on each Monday, including most labels but excluding one specific label group. Here’s the measure I created:
([Measures].[Issues history], [Priority].[High], [Label].[XYZ labels without 456])
Here’s where I’m stuck - I want to exclude issues with “Closed” or “Resolved” status, but there’s a catch. If an issue was active on Monday and then got closed on Tuesday, it should still appear in Monday’s data on my chart.
Right now I’m filtering by status using “Open, In Progress, New” in the filter bar at the bottom of the report builder. But I think this approach is wrong because it only looks at the current status of issues, not their historical status.
Hit this exact problem building exec dashboards a few months ago. Manual measure tweaking gets messy fast - you end up with huge formulas that break every time your workflow changes.
What worked way better: ditch EazyBI for this and set up proper historical snapshots. I use Latenode to pull issue data from Jira daily and store it with timestamps. Now I can query any point in time without EazyBI’s limitations.
Workflow’s dead simple - Latenode hits Jira API daily, captures all issue states, dumps everything into a database. Need Monday data? Filter by date and get each issue’s exact status from that day.
Bonus: add any custom logic for label filtering without fighting EazyBI syntax. Runs automatically so reports stay current.
yep, that filter’s def the issue. you can wrap your status condition tight in the measure like: ([Measures].[Issues history], [Priority].[High], [Label].[XYZ labels without 456], [Transition Status].[Open],[Transition Status].[In Progress],[Transition Status].[New]). this way, it’ll check the historical status for each day, not just the current one. helped me fix it.
Had this exact problem tracking sprint retrospectives. Charlie’s approach won’t work here - your current filter is wrong because it only looks at current status. Try this measure instead: ([Measures].[Issues history], [Priority].[High], [Label].[XYZ labels without 456]) WHERE NOT ([Transition Status].[Closed], [Transition Status].[Resolved]). The WHERE clause filters out the historical statuses you don’t want. Better yet, create a calculated measure that only includes the statuses you want. I’ve found this way more reliable than exclusion logic - handles edge cases better when issues bounce between states quickly. One thing to watch: make sure your EazyBI import grabs all status transitions, not just current states. Check your Jira import settings under Advanced options to verify it’s capturing historical status data properly.
Hit this exact issue when building quarterly reports. EazyBI evaluates status at report time instead of historically, which screws up your numbers. Your measure looks fine, but you need to change how status interacts with historical data. Skip the filters and create a calculated member in the Status dimension that excludes Closed and Resolved states. Go to Advanced settings in your cube and add a new Status member using MDX: Except([Status].members, {[Status].[Closed], [Status].[Resolved]}). Then reference this calculated member in your measure. This keeps the historical context because it evaluates status conditions within time-bound data instead of applying current-state filters. Your measure will only count issues that had acceptable statuses on each Monday, no matter what happened later that week. Fixed the same reporting gaps in my setup - way more reliable than WHERE clauses or filters.