No Worklogs in Issue for Jira Expressions

Hi,
I have started playing with jira expressions but can not get worklogs from issue (changelogs also)
Documentation told nothing about that
https://developer.atlassian.com/cloud/jira/platform/jira-expressions-type-reference/#issue
POST returns error ’ Unrecognized property of issue: “worklog”'.

It might be useful to filter worklogs on backend for common legacy issues with thousands of worklogs.

What about worklogs future in jira expressions?

Thank you.

You should create one or more tickets on ecosystem.atlassian.net, in project ACJIRA, Component “Jira expressions”.

This is something we thought of adding, but haven’t prioritized so far. It would be really helpful if you could explain your use case in more detail. How would you like to filter and retrieve worklogs? Isn’t the currently available set of REST APIs for worklogs enough?

Hi Krzysztof,

I have added [ACJIRA-1986] - Ecosystem Jira also.

We are building time tracking reports. To build report for instance for last week we get all issues worklogs then filter them against last week.
But sometimes we get tenants with enormous (e.g. 42 megs) worklogs per single issue (common legacy issue). And it is really issue to get report built.

It would be great to reduce workogs data with something like:

expression: 'issue.worklog.worklogs.filter(log => log.startDate>' + '2019-01-01)',
            context: {
              issue: {
                key: issueKey
              }
            }

or even better with issues list with filter - map - reduce and get all filtered issues with filtered worklogs.

One option is split issue by period but I can not tell it to tenant))))
Another option is paginate worklogs retrieval to get reduced data per request, but it cost a lot of requests and time for filter it at client side.

Thank you.

There is a REST API to get worklogs after a specific date. It returns a list of IDs, which you can then use to get the full worklog data.

It seems using these APIs would solve the problem with too many old worklogs?

I have 3 worklogs:
01.01 1h, id = 1
01.02 1h, id = 2
01.03 1h, id = 3
On 01.04 I have updated id = 2 with logged 2h
I want to get workload for period 01.03-30.04.
Please confirm I get 1h with Get IDs of updated worklogs

Please note to build report we work with ‘started’ field, worklog could be created/updated another time.

The API returns all worklogs updated in the given time. The worklog with ID 2 would be returned if you asked for worklogs updated from 01.03 to 30.04, since you updated it on 01.04 which is within the requested time period.

But users want to build report for period of works(week/month, shifted), not for period of updates. So you link can not be used for that.

Alright, thank you for the explanation. We’ll think about expanding Jira expressions, or the REST API for worklogs.

Thank you Krzysztof, that will have great impact for time tracking reports!
For /search we have jql with worklogDate and worklogAuthor filters. It would be great to have similar for /worklog. But best effort I expect from jira expressions and possibility to filter worklogs with issues list.

What if I wanted to add a Validator that does “You must log work to advance this issue”? I’d need the worklog of the current user by using a Jira expression.

You can perhaps use one of these time-tracking related issue fields:

  • originalEstimate : The original estimate of how long working on this issue would take, in seconds (Number).
  • remainingEstimate : The estimate of how much longer working on this issue will take, in seconds (Number).
  • timeSpent : The time that was spent working on this issue, in seconds (Number).

Then again, these won’t allow you to connect the logged time with particular users.

There is a way to create a validator that does it anyway. The idea would be:

  • Maintain an issue property with the list of users that logged work.
  • For example, your app could update it whenever it receives a worklog webhook.
  • Check that property in your validator against the current user.

Using entity properties in this manner is a common pattern that allows you to write almost any logic in your validator, even if something is not doable directly in Jira expressions.

Does that mean doing this on every issue? I’m afraid this is too much of a workaround. I need a general solution as it is needed in a workflow transition validator …/secure/admin/workflows/ViewWorkflowTransition.jspa.