Dick Community Champion

Hi Nagaraju, I take it that you've checked the project screen schemes down to the screens used therein? Those should contain the desired "status" field.

Just like @John Funk said. Please realize that up to now, you've actually been cutting corners on the security front by using the 'any logged in user' group. So it's time to man-up, bite the bullet and provide proper roles to the projects. There is no other way.

Hi Martina, Team capacity is a part of the "plan" configuration. You find it as a tab on the Plan display. Mind you, only Kanban projects can deal with hours (Scrum uses story points). In the team tab, you can edit the team configuration. This is where you define the Capacity (weekly hours) amount. It is also where you…

Why not use Jira all by itself? LookupIssues using JQL 'key' = {{issue.key}} and issuetype in ( "type3")

To keep management manageable, I would recommend sticking to a single version. With 100 people, you get 100 ways they would like their screen to be. just my 2 cts. :)

I'm guessing you're using a Kanban board. Try doing a release. The Kanban board sub-filter (go to Board Configuration - General to see it) filters-out the released jira issues: Kanban board sub-filter: fixVersion in unreleasedVersions() OR fixVersion is EMPTY

Hi Martina, Your team can only manage 190 hours in a set time period (sprint). If you add-up the 15 + 50+ 125, you arrive at 190, which is all the team can spend for that period. So you're short 5 hours, that would have to be done in the next available period.

Hi Pragasen, My thoughts on on your query were mixed: * It appears as though you are using the Kanban principle * However, you might be unaware that Kanban is about having as little as possible active issues on the board. This would mean that the number of stories with status done exceeds the stories with other statuses by…

Atlassian's solution (safest) is described here: how-do-i-disable-remove-inactive-active-users-in-bulk-1093012826.html it also states there that the required functionality is under consideration in their backlog. Issue JRASERVER-8047 You might want to follow that or at least vote for this issue to provide more incentive to…

You can use Automation for Jira. Trigger would be the transition of the issue. We would check if the status transfer is prohibited by your prerequisites. If so, we would restore the ticket to the original status. So for this, you would need the history of the status field of the ticket to be able to get the original status…

You can access the names of the list using the technique Atlassian shares and then use the suggested abbreviation technique to trim them down. Some of the Atlassian pages are really worth it !

Hi Martina, Your problem description would suggest a two step automation: * Finding the epic (or making it with the correct group name if necessary, then "find it"). * Finding the Monday tasks under consideration (or make it if necessary). Note that after epic finding, you can use the For Stories (or other issues in Epic)…

Hi |Sam, From your question I notice that you're already using automation. Good on you. You might want to check the smart value abbreviation techniques that Atlassian shares, to abbreviate the input of the second value.

Hi Sandeep, If your instance is taking users aboard from an Active Directory and the users have been deleted there, they get an [x] indication in their name in Jira and they get marked in the database as being inactive. There is no need to delete them any further (other than to clean-up your DB).

Exactly! There is no reason whatsoever to put these restrictions on the Team project sprints in the aforementioned way. Even when I gather their own issues on another board (so without the epic issues of project A, yet still with the epic link fields of the issues referring to the epics in project A), the restrictions on…

USE YOURJIRADBNAMEDECLARE @@MDT nvarchar(255) = 'YOURPROJECTKEY'SELECT fa.id, concat(p.pkey,'-',ji.issuenum) as 'Issue', st.pname as 'Status', concat('/opt/jira-shareddata', '/data/attachments/', p.originalkey, '/', ceiling((ji.issuenum / 10000))* 10000, '/', p.originalkey, '-', ji.issuenum, '/', fa.id) as…

Hi Nenad, For some reason my posted answer is wiped. It describes the way how to retrieve filenames and locations on a project basis. I'll post it under this message, in the hope that it won't be deleted as malicious code.

After the When statement, you would typically put the link containing the linked issuekey in a variable like {{linkedOrigin}}. Then you can use smart values like {{linkedOrigin.customfield_xyz}} to transfer the values to your current issue Thing is: I suspected the "change type" and "affected product" are custom fields.…

cleaned up double post, apologies.

cleaned up double post, apologies.

Hi Moshe, It's all in the order of things: * To avoid orphaning your 53 sub-tasks, move them in bulk and change their issue type to task. * Then move story Jira-1234 and change the issue type to epic. * Then move the 53 tasks to your epic by filling the epic link field of these issues If you're afraid of loosing the 53…

A good way to deal with this would be contacting the company that built the plug-in and make a suggestion to incorporate this feature. They might put it on their backlog.

I see "original" as the first entry of the time estimate. This value could change prior to the ticket being "in Progress" . Hence, you should poll the time estimate at the moment the ticket is pulled into the sprint, that could differ from the "original" !

Some plugins have the possibility of restricting their usage by assigned role in a project. Configuration of such restriction should be located in the administration - applications menu. These are grouped per plugin.

Original estimate of an issue is a historical value (that could've changed upon refinement and later adjustments prior to the issue being in progress)

You need to install the plugin. (you won't get charged, there is no license to obtain). We're running 9.12.7 (LTS) Jira with the Automation for Jira 9.1.1 plugin here.

The datacenter Jira has the userhistoryitem table holding the kind of stuff that has happened (look at issue, make sprint, etc.) It might not be available to cloud admins though.

I'm not sure which calculation you refer to (the excel is not quite clear) But I've seen calculations with and without the weekend giving rise to differences.

Hi Sven, Sorry to have kept you waiting (I've been on a small vacation). You can harness all your issues in one project, with the component as a discriminator for four boards. The jql for each of the boards would be like: Project = (MainProject and issuetype is epic ) or (MainProject and component = X ) For each board, you…

Hi Markus, you might want to use the change log of an issue to access the previous value of the version: This has been described by @Stephen Wright in this forum entry.