I search for Issues in the IssueProvider:jqlFetchIssues function, using the JiraRestApi issue service. An empty JQL is used, which should also be changed, probably based on the user_map.yml data.
This method does not work the best, since #5 is an issue. It wouldn't be if getTotal() on the search of worklogs would provide the latest id of all worklogs, but it doesn't.
Issues do get deleted sometimes and I incrementally check the issues, merging their timesheets on the required clause (employee's name for now). I would like to do this in batches of 50 until the offset reaches the max worklog count. But we have a problem, requiring a somewhat hacky solution.
Scenario
1000 issues have been created
50 issues have been deleted
Now, getTotal() on the search query returns 950. Looping the way I currently am, would go from 1 to 950, fetching all worklogs from issues separately. Now, if 50 issues have been deleted before the 950th issue, we will stop at id 950 and the last 50 issues, 951 through 1000 will get skipped.
Solution
The current solution I have employed, just adds a constant number relevant to my Jira Project to make sure I envelop the whole issue space. This is bad in two ways.
We might miss issues and therefore worklogs on bigger projects, which have more issue deletions.
We always do too much work if we want to make sure we get past each issue.
Also, checking if the lines are valid is not an option, since a deleted issue acts the same as one that has not been created. It just responds with false.
As far as I have seen, there is no direct way of getting worklogs, opposed to the way I get them. By getting Issues from the IssueService and then fetching worklogs there.
I search for Issues in the IssueProvider:jqlFetchIssues function, using the JiraRestApi issue service. An empty JQL is used, which should also be changed, probably based on the user_map.yml data.
This method does not work the best, since #5 is an issue. It wouldn't be if getTotal() on the search of worklogs would provide the latest id of all worklogs, but it doesn't.
Issues do get deleted sometimes and I incrementally check the issues, merging their timesheets on the required clause (employee's name for now). I would like to do this in batches of 50 until the offset reaches the max worklog count. But we have a problem, requiring a somewhat hacky solution.
Scenario
Now, getTotal() on the search query returns 950. Looping the way I currently am, would go from 1 to 950, fetching all worklogs from issues separately. Now, if 50 issues have been deleted before the 950th issue, we will stop at id 950 and the last 50 issues, 951 through 1000 will get skipped.
Solution
The current solution I have employed, just adds a constant number relevant to my Jira Project to make sure I envelop the whole issue space. This is bad in two ways.
Also, checking if the lines are valid is not an option, since a deleted issue acts the same as one that has not been created. It just responds with false.
As far as I have seen, there is no direct way of getting worklogs, opposed to the way I get them. By getting Issues from the IssueService and then fetching worklogs there.