Ignacio Pulgar Expert

You may also add AFTER <date> and/or BEFORE <date> next to "status CHANGED" in order to narrow the time frame when the modification was made.

Natively, without any addons you may just try the following JQL: status CHANGED BY <username> You may narrow the kind of change by adding FROM <status> and/or TO <status>, but it needs to be queried on a per user basis. Of course, you can also filter by project or any other fields to get the info you are looking for.

Cannot think of an example. Maybe one of both systems stops the looping after 3 times. You might prevent that loop from happening again by changing the Mail Handler's Bulk property, as described in the docs: This option only affects 'bulk' email messages whose header has either its Precedence: field set…

Right, querying the DB is not possible on Cloud. I'd suggest opening a ticket with Atlassian Support so that they perform the query for you: https://support.atlassian.com/contact/#/ Alternatively, I think you may develop a solution which queried one of the JIRA REST API's:…

Mmm... Found this: https://confluence.atlassian.com/jirakb/search-for-inactive-users-346947771.html The workaround then would be querying against the database. The KB article above contains the SQL sentence for getting the list of inactive users, so now you just need to build a longer SQL sentence using the one in the KB…

The JQL function inactiveUsers() is provided by ScriptRunner plugin, and it won't work unless your JIRA instance has that additional addon, which seems not to be the case. There's no easy native alternative. A workaround could be adding inactive users to a group (ie: inactive-users) for flagging those users as inactive.…

It seems you've possibly experienced a mail loop. That's something that typically occur when auto-response emails are sent, like those 'out of the office' ones. Read the paragraphs that contain the word 'loop' in this page:…

"Components" is the only built-in field which counts with the functionality of setting a default assignee depending on its given value on issue creation. While that feature is easy to emulate for other fields with the help of a plugin, it is good to use Components for categorising issues in a way that take advantage of…

You're on the right track. Just note that dates with no explicit time default to 00:00 hours, so that query wouldn't return issues created during 2017-01-31, except those that might have been created exactly at 00:00 hours. You may fix it by using "2017-01-31 23:59" instead, or even < 2017-02-01.

I suspect you have one extra carriage return between both lines, which is causing the weird display of the table. Just remove the empty line between the column headers and the first row and the table will be displayed correctly.

Try copying this in Text mode: ||column 1||column 2||column 3|| |cell value 1|cell value 2|cell value 3|

May you click on the Text tab of the actual result to see its wiki notation?

Have you tried the wiki notation of a table in conjunction with a behaviour? That way you may define one or more tables with the appropriate column headers for any project & issue type combinations.

You may create a table with wiki notation: ||column 1||column 2||column 3|| |cell value 1|cell value 2|cell value 3| If you would like to get a more sophisticated table, you may want to have a look at the Table Grid Editor plugin, which lets you create a table as a custom field.

Ensure the statuses used by AFTDC issues are correctly mapped to any columns. Otherwise they won't appear in your board. Regards

You need ScriptRunner's Behaviours for prepopulating the Desciption field that way: https://scriptrunner.adaptavist.com/latest/jira/behaviours-overview.html#_setting_a_default_description

If you have ScriptRunner, then have a look at how to achieve it through Behaviours: https://scriptrunner.adaptavist.com/latest/jira/behaviours-overview.html#_setting_a_default_description

Hi Jana, I'd suggest either opening a ticket to TGE Official Support team: https://support.idalko.com/servicedesk/customer/user/login or send an email to: support.tge@idalko.com Once your issue gets fixed, it would be great if you could update this question with the answer, in order to hep other users experiencing a…

Try this quick filter: Flagged = Impediment

Have just created the quickfilter suggested by Warren and it works like a charm.

Have you considered using the built-in Rank field instead? The Rank field controls the vertical order of apparition of issues in any boards, either kanban or scrum, and the higher position of the issue means a higher priority. Using Rank they will be able to change priority by dragging a card and dropping it in another…

Then I would suggest to create a new question including the tags: Jira and Tempo Timesheets, together with your last screenshot (the one showing 40 hours logged in the same day). That way you will probably get the correct answer. Alternatively, you may open a ticket with the addon's support team: https://support.tempo.io…

Is that screenshot from Tempo Timesheet addon?

Now your question is understandable, but I do not know the correct response. So, I'd suggest you to open a new question specifying that you are referring to Tempo Planner, including both JIRA and Tempo Planner tags. Regards

So, as the worklog starting date defaults to the current date at the moment the user clicks on Log Work, the user should change the date to a previous one if he is logging 40 hours of already done work.

The selected date represents the date at which the logged work started, and not the date in which all the logged work was actually done.

What do you mean with "unplanned issues" exactly? All of the following choices are queriable through JQL: * issues lacking a due date * issues in certain status(es) * issues not assigned yet * issues that do not belong to a version * issues which have not been added to a sprint and are still open May you possibly clarify…

Really interesting thoughts, Nic!

One single automation rule would be more efficient, as once the state had been found true in a IF condition, the corresponding 'Then' action will be performed and no further condition checks will be made.

Glad to hear that! Regards