We want to use Tempo timesheet reporting. Howver- our teams are ad-hoc per issue, and there is one lead per issue with additional people reporting on this issue. People may report hours on several issues during the month and their reports should be approved by each of the respective issue- leader, only for the hours related to that issue.
I see that the TEMPO approval process assumes that one team lead approves the entire report of a person.
Whats the best way to achieve our way of approval?
Although this is not a built-in feature, is it something that can be implmeneted by scripting, using the TEMPO API or SIL, dor example? In your blog, you give many explenations about using the API but I did not find if one could use this API from within JIRA (although my guess is that it should be possible).
I was checking this with the development team and they confirm that there is no API available to make this possible. The approval process is always by user and period. It can not be done on issue level.
You might be able to limit hours approved by the "wrong" reviewer by using the approval process on a weekly basis
Ok, I voted on the link you sent.
I am not very optimistic to see this implemented given the long time this is open. Quite strange because sounds quite a common need to me.
I will see if we can "live" without this or if we will abonden the idea to adopt Tempo Timesheet altogether.
Thanks anyway for checking this for me,
I have my doubts if any time tracking solution would/should implement approval based on single issues (seems to granular to me), but if you are interested in a completely different approach for approval, have a look at ictime. Approvers are defined per project, so one (or various) approver/s is/are responsible for all work logs of the issues of one (or multiple) projects, regardless of user. This would be perfect if your issues belong to different projects. If not, the approver also has the option to generate a report by a single issue and then approve only work logs for this issue (but there is no limited access, i.e. approver could also see/approve other work logs within the same project).
Maybe this could be a workaround: If the permissions to add worklogs to an issue are granted only based to a custom field of type "Group picker". When an issue is created this field is set based on whoever can report on the issue, so people may log work. when the issue is transitioned to, for example, "finished work", then the custome field is made empty, essentially removing permission to update worklog.
This is not exactly the same as approving the logs, but at least avoids the situation that someone updates the logs in an un-appropriate workflow state.
In a world of dark-scrum, faux-scrum, and scrum-butt, the question still remains: What is scrum and how do you do it “right?” That’s the question we set out to answer. I'm Max, I've been teaching c...
Connect with like-minded Atlassian users at free events near you!Find a group
Connect with like-minded Atlassian users at free events near you!
Unfortunately there are no AUG chapters near you at the moment.Start an AUG
You're one step closer to meeting fellow Atlassian users at your local meet up. Learn more about AUGs