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?
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:
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.
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.
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.