Forums

Articles
Create
cancel
Showing results for 
Search instead for 
Did you mean: 

Tempo Timesheets - Unable to log time in Jira issue where "jira.issue.editable" is false

Nupal Patel
I'm New Here
I'm New Here
Those new to the Atlassian Community have posted less than three times. Give them a warm welcome!
December 2, 2021

In Jira Service Desk, we have a change management workflow with the "Implementing" step. This step has a property key "jira.issue.editable" set to "false" which prevents all users to edit the issue whilst it's in the "Implementing" state. 

Now we have installed Tempo Timesheets and users can not log time whilst the Product change issue is in the "Implementing" state. It gives an "Error: Something went wrong". 

Is it possible to have another property key set to allow "Log Time" for all users whilst the issue is in implementing state? 

2 answers

0 votes
Rob_Huntley_Tempo
Contributor
December 2, 2021

ake a look at this thread here in the community:

https://community.atlassian.com/t5/Jira-questions/jira-permission-edit-vs-jira-issue-editable-properties/qaq-p/707072

 

I think it's quite helpful in respect to permissions versus properties.

 

Tempo has its own permissions and its worklog is separate from the Jira issue.  Perhaps try restricting the jira.edit permission instead at transition - and insure users still have the work on issues permission in Tempo.

I haven't tried this myself but check it out.

Documentation on Tempo permissions for Jira server are online here:

https://tempo-io.atlassian.net/wiki/spaces/THC/pages/285343748/Permissions+-+Tempo+Server

0 votes
Robert Wen_Cprime_
Community Champion
December 2, 2021

Hello @Nupal Patel 

 

I'm going to "guess" that it's not possible since the act of logging time is, in essence, editing the issue.  

But, I could be wrong.

Nupal Patel
I'm New Here
I'm New Here
Those new to the Atlassian Community have posted less than three times. Give them a warm welcome!
December 2, 2021

Thank you for your reply. Having posted earlier questions, we have found 2 workarounds:

1) move the ticket back to the previous state where the editing is possible. 

2) By default, we create a sub-task for each production change, sub-task workflows are different, which means the engineer supporting the change can log against the sub-task but not the parent change ticket. 

Like Robert Wen_Cprime_ likes this

Suggest an answer

Log in or Sign up to answer