jira.permission.work.denied does not prevent work logs

[Paul Alexander]

I'm on Atlassian Cloud - 7 year expert admin. What is the deal with this workflow property (jira.permission.work.denied). It has been intermittently being honored for 6 months now, but as of the past month or so, it is no longer honored. So, I figured I'd spend some time here finding the problem, but it seems answers are all over the place even recent answers. At this point though, none of the workflows where this property is employed are preventing a work log like it should and once did for so many years. I use JMWE add-on as well if curious, but this property is not part of that bundle.

I include this property pair (jira.permission.work.denied : denied) on every step and on every transition for a given workflow including the initial create step, per this documentation, but a work log entry can still be added there. This property once accepted "true" since that's how I had it setup for years, but it seems "denied" is the proper verb at this point. Nonetheless, things worked for many, many years and are now not.

Use case: I don't want work logs on an Epic issue type.

It's not just this issue type though that has this problem. I actually have places where this property is not present on a workflow, but we still cannot create a work log there. For instance, I have a custom parent issue called "Foo" that will not allow a work log.

Should I escalate to my support channel? Figured I'd start here...

[Lukas Krajnak]

Ok, 

I spent a bit time on this and I found workaround/solution to this issue. To get this property working you need to assign "All Unassigned Issue Types" to workflow which has this property set.

Here is a link to a screenshot:https://www.dropbox.com/s/hca37edeaf1swff/Restricting%20time%20login.png?dl=0. In this case "BPS (Sprint) Default Workflow - Change-Emergency v.3" has property "Jira.Permissions.work.denied" set in some statuses. Other workflows have not the property set. So if "All Unassigned Issue Types" are assigned to this workflow ("BPS (Sprint) Default Workflow - Change-Emergency v.3"), time login restriction works for all issues with issue type "Change-Emergency". If I assign it ("All Unassigned Issue Types") to any other workflow which has no property set, it won't work even for issue type "Change-Emergancy".

[Paul Alexander]

Nice find, Lukas. I'll see if I can apply the same logic to my situations. Thanks for sharing.

Add yourself as a watcher to and vote for the JIRACLOUD issue I linked above if you haven't already.

[Lukas Krajnak]

You are welcome Paul, hopefully, it will work for you ;)

[Lukas Krajnak]

I figure out how to workaround this. I have old workflows to which I added this property to status and it works. All newly created workflows ignore this property and users can log time. If I copy old workflow and then change it to whatever I need and then add this property it works!!!  

Regards, 

Lukas

[Lukas Krajnak]

Experiencing the same issue and it is a huge blocker for us as there is no other workaround :(

[Paul Alexander]

I guess I have a short term memory since this is an outstanding issue and one that I even commented on as late as last month...I guess we wait patiently.

https://jira.atlassian.com/browse/JRACLOUD-67154

[Anil Bondada]

I had the same problem with that property. We were on cloud as well. But after some testing we came to know that it won't work immediately(don't know the reason). Give it some time. In our instance, it took around 30 minutes for the property to kick in and block work logs. We had Tempo as our time tracking though.

[Paul Alexander]

Good tip, Anil. I, too, have been using Tempo Timesheets for several years as our time provider. However, for several of the issue types in question, I applied the property 3-4 weeks ago and where the property is "denied", the issue type still allows a work log. But, I'll do a little more assessment in our instance just to rule that out. Thanks.

[AKBAR]

Hey @Paul Alexander , Good day..

Akbar here. We are also using Cloud environment.

Can you suggest me a field on screen where I can find the total hours expended on a particular ticket based on Tempo logged hours.

If a user has logged 5h on tempo in different days, I want the sum of hours to be displayed on the View screen operation.

Is this possible?

And one more thing is like, if a user fails to log he should be intimated on daily basis.

[Paul Alexander]

Akbar, from the issue navigator page, you can include these columns in the result set.

• Sum of Original Estimate
• Sum of Time Spent
• Sum of Remaining Estimate

Tempo will display this data by default on the Jira Issue view. If using the New Jira Issue View (Labs feature in your profile>settings), the Tempo plugin is buried so you cannot readily see it on screen.

However, I'm not aware of any means to display these 'Sum of' fields on a transition screen used in a workflow operation.

This is a big problem I wish Atlassian would solve. Jira has these three pieces of data but does not make it available through its API.

The best we can do is expose the 'Time Tracking' field on a screen. But this does not sum the hours; it only displays the hours spent on the issue itself (parent or subtask).

I assume you would like users to be reminded to submit their post their time no a daily basis. This is not supported natively from Tempo. Maybe a plugin? In Tempo's Scheduler Configuration, you can notify users on a weekly, biweekly, or monthly basis and define the period end date when such notification will be sent to include sending mail once to all users and then sending mail n days later for those who have failed to submit their timesheet.

[AKBAR]

Hey @Paul Alexander ,

Thank you so much for your response.

Yeah I got a clear idea now on Tempo notification.

It is usually sending for weekly as set earlier.

As soon as I changed the card layout option to "sum of time spent" I got it done.

Once again Thank you man.

Regards,

Akbar.