Druvis Cukurs (Lineset) Atlassian Partner

We checked this ourselves in October: hours logged in the other app reach Jira under that app's own account, with its text in place of the person's comment. So before step 4 there is a choice to make. Keep the report inside Jira. It reads only what Jira holds, so those hours count in every work item, space and client…

Hi, @Adam Walczak! If what you were after was invoicing from worklogs, one thing to watch whichever way you go: don't bill from the work item export. Its Time Spent is the all-time total, so anything logged before the month gets charged again. The month's own hours come from the worklogs: worklogDate >= 2026-10-01 AND…

Hi @Max Mykhailenko , On the worklogs question: in most teams they feed the timesheet and rarely the review. One filter earns them a place, though: parent = ABC-12 AND worklogDate >= startOfWeek(-1) AND worklogDate < startOfWeek() It lists the epic's stories that had time logged last week. That's often the most honest…

Hi, @Kamil Stepien! Two things the thread doesn't have yet. First, the native gap you're working around has a suggestion of its own: JRACLOUD-88003, "set dependencies between version releases" (Gathering Interest, 66 votes). Your Release Package write-up is the clearest description of that gap I've read, so it's worth a…

Hi, @Vikrant Yadav! The awkward part is that an epic is never in a sprint itself, only its stories are. So "which sprints was this epic part of" really means "which sprints did its stories land in", and you build it from the children. Search parent = ABC-123 ORDER BY sprint ASC, switch to list view and add the Sprint and…

Hi, @tapan! One thing about the accepted pie chart, as Trudy pointed out: it puts each work item's whole Time Spent on its current assignee. Hours logged by someone else, or months ago, still land on the assignee. For hours by the person who actually logged them, over a period, natively you need the worklogs. worklogAuthor…

Thanks Marcin, both good additions to step 6. Rates by date. Agreed, that's where the hours match and the invoice still doesn't. Logline (ours) applies the rate in force on the day each worklog counts on, so a new rate from 1 November leaves October's amounts as they were. Rates can be set by client, space or person.…

Hi, @Avijit Nath! The reason the native options keep falling short: Time Spent is one running total per work item. worklogDate >= "2026-10-01" AND worklogDate <= "2026-10-31" finds the stories with work logged in October, but the Time Spent you see and export is each one's lifetime total. And Σ Time Spent adds subtasks…

Hi, @Irina Zdanovych! For what Version Workload showed, remaining work per person in a version, the closest native setup is a dashboard gadget: Save a filter for the version's open work: fixVersion = "1.4" AND statusCategory != Done (with your version's name) Add a Workload Pie Chart gadget on that filter, grouped by…

Hi, @tcunha! You don't have to go work item by work item for this. Jira has a worklog feed that skips the per-item read entirely: GET /rest/api/3/worklog/updated?since=<epoch ms> returns the IDs of every worklog created or changed since then, 1,000 a page POST /rest/api/3/worklog/list with up to 1,000 of those IDs returns…

Hi, @Sara Salem! Glad the pivot table worked. For the per-sprint half of this, so there's no export to redo each sprint: I built Sumline, a Marketplace app with a table that groups story points by sprint, splitting an epic across the sprints its work items are in, with a total line and an Excel download. It doesn't group…

Hi, @Anna Laptyuhova! To put the replies together: skip the web request and do the edit inside a branch to the parent (Branch rule / related work items, then Parent). Inside the branch, Lookup work items for the parent's sub-tasks and edit Original estimate with Bill's sum. Two more triggers keep it right: a sub-task…

Hi, @Noalen Pell! For anyone landing here with the same symptom: as Noalen found, the plan's timeline counts a child's estimate only when the child has dates. If yours have dates and still don't count, Joshua's two settings are the next place to look: the work type in the plan's hierarchy, and an estimation method set for…

Hi, @deseymour! Glad Trudy's fix got the rule working. One thing for anyone who finds this thread later with the same rule: it only recalculates when a task's story points change, so the epic's total drifts when a task moves to another epic, is deleted, or is created with points already set. Each of those needs its own…

Hi, @Kim Wright_qh63d1! One addition since you're on Premium: issue in portfolioChildIssuesOf("ABC-1") returns every level under the epic in one filter, sub-tasks included. A Plan built from that filter shows it as a tree with roll-up columns. Another route, and I should say it's mine: Sumline takes a saved filter or JQL…

Hi, @Jamie Scott! For the table you described, Jira can give you exact counts without an agent: save a filter for the epics' children (project = ABC AND parent is not EMPTY AND issuetype in standardIssueTypes()) and put it in a Two Dimensional Filter Statistics gadget with Parent on one axis and Status on the other. Each…

Hi, @richa bhatnagar_wyhfd6! For mid-sprint checkpoints Jira already computes the numbers, so it's safer to let the agent comment on them than count them itself: The active sprint's header in the backlog shows the story points in To Do, In Progress and Done. The Sprint report and burndown show points completed against what…

Hi, @Lorinda Quesenberry! Leaving the epics out fixes the double count, and their own points are still worth keeping as the estimate made up front. Put each epic's points beside its stories' total rather than inside it, and the gap shows which epics grew during the PI. Sumline is mine, so read this with that in mind: it…

Hi, @007989! With the re-fetch and the size check above, the rule shouldn't write 0 again. If the parent's total is mostly there for people to read, here's another way. Full disclosure: I make Sumline, which shows the parent's total on the work item view by reading its children when you open it, so there's no rule to race…

Hi, @Radhika Vijji! Without Plans, a dashboard can get most of the way across boards: Commitment and status: put the quarter's epics in a filter (issuetype = Epic AND fixVersion = "2026 Q4", or a label) and show it in a Filter Results gadget. Story level: use Two Dimensional Filter Statistics of their children, by Parent…

Hi, @rayyan.siddiqui! Plans, the timeline and the Story/Task level point are covered above, so this is for the dashboard side, where Jira's gadgets stay flat lists. I built Sumline, so take this with that in mind. It has a table of every epic that opens level by level: epic, then stories and tasks, then sub-tasks. Each row…

Hi, @An-Sofie Smet! The saved parent = … search suggested above is the dependable fix until the panel is fixed: it loads the Σ column every time. If what you need is the epic's whole original estimate, Sumline (full disclosure: it's my app) shows it in a panel on the epic itself. It adds up every work item under the epic,…

Hi, @Alejandra Palacio Perez_ai2u5r! On the not-done sum you asked about: if you split the lookup to stay under the 100 cap, split it by status category. Use parent = {{issue.key}} AND statusCategory != Done in one lookup and parent = {{issue.key}} AND statusCategory = Done in the other, each summed into its own field. The…

Hi, @Roberto Manes! The list view export covers the hierarchy itself: search issuetype in (Initiative, Epic), add the Parent column and export, and each epic row names its initiative. What it can't give you is each initiative's and epic's totals from the work under them. For those, I built Sumline (so I'm biased). Its…

Hi, @Richard Milea! Jira's own gadgets only count, so the native route is a scheduled automation rule. Look up the work items with your filter's JQL, then write {{#=}}{{lookupIssues.Story Points.sum|0}} + {{lookupIssues.Test Estimation.sum|0}}{{/}} into a number field on one "dashboard" work item, and show that work item…

Hi, @Ramesh Krishnan! To build on the accepted answer: put Status Category on the gadget's other axis instead of Status. Each epic's row then reads To Do, In Progress and Done, so you see how many of its stories are finished, not only how many there are. Sumline is my app, so weigh this accordingly. Its space tab lists…

Hi, Patrick! For the epic side, here's what we use instead: a saved search parent = ABC-1 in the list view, with the Σ Original Estimate, Σ Time Spent and Σ Remaining Estimate columns, shows where the epic stands. The timeline's progress bar shows how many of its work items are done. I built Sumline for exactly that view,…

Hi, @Ed Maschler_cmj5al! Until the gadget reads the Σ fields, point its filter at the level your team estimates on: for sub-task estimates, add AND issuetype in subTaskIssueTypes() to the filter, and the flat field it reads is the right one, per assignee. Keep stories out of the same filter if they carry estimates too, or…

Hi, @Ubaroz! To catch the ones that already slipped through: a saved filter statusCategory = Done AND issueLinkType = "is blocked by" lists done work that still has a blocker link. It matches the link, not the blocker's status, so open each one's blocker to check it's still open.

Hi, @Anna Laptyuhova! On the double counting: if a rule writes the sub-tasks' sum into the story's own Original Estimate, any report that also reads the sub-tasks counts those hours twice. Write it into a separate number field instead (say "Sub-task estimate total") and leave Original Estimate to one level, or estimate…