Jack Brickey Expert

this isn't about a "Resolved status" it is about the "Resolution" field. You can have one or many 'done category' statuses (Closed, Done, Cancelled, etc.). For each transition into the various 'done category' statues you should set the Resolution field. This can be done via a simple Post Function and set the resolution to…

I think i would start by answering the question "why did we stand up a service desk in the first place?" Then you will understand if the original needs have been negated or not.

i'm not sure this will improve 'total time to complete' but at a quick glance I would consider breaking this down into smaller rules if possible as it helps w/ rule performance.

and if you want the closed issues to be counted you would need to re-transition them. there are some ways to deal w/ this other than reopening them if you really want to go that path.

absolutely. that is in fact often used. Semantically, you associate issuetypes to a single workflow. the relationship of WF:Issuetype is 1:N. now i would caution you not to go to crazy with this. keep your WFs as simple as possible especially at first and then carve off an issuetype when you really need to do something…

well that really depends on what you are trying to do. TBH, I rarely use multiple boards per project. Once obvious use case would be if you say had multiple teams doing their own thing. And maybe you use Components to categorize their work: team 1 = platform, team 2 = UI, team 3 = stack. Then you could create three boards…

resolved is a generic word. I can't be sure whether resolved here equates simply to your done status OR if it is associated with the Resolution being set. It should be pretty easy to test this out. Given that you are showing 0 of xx issues resolved my suspicion is that it is associated with Resolution being set and I…

if you are referring to how the issue key appears w/ strikethrough that is done when the Resolution is set.

what is unique about the second board? is it possible that it includes issues from another project? if so verify that the grp-engleads has permissions in the other project(s).

there isn't a way to do this on the Kanban board. you could create a filter that would illustrate what you want and use on a Dashboard gadget if that would work for you.

TBH, I have never tried and I have always understood (?) it cannot be done. However, you can try here > admin > issues > issue types, find Epic and click edit? I don't have a test instance where I could try it. Let me know.

sorry, can you give an example of a system notification?

you cannot select the date dynamically on the dashboard (that would be nice). But certain gadgets (created vs. resolved) allow you to specify calendar info like last 30d. So you would need to build the date into the filter that you would use in your gadgets. As for the gadgets, maybe using the two dimensional gadget would…

there isn't a system notification config. notifications are done based upon a notification scheme in projects. if you don't want to be notified then just ensure that you are not in a role/group that gets notified. 

OOTB Automation does not support moving an issue to another project. Here is a thread you might find interesting. Nic provides some insight here and mentions there are apps that could help you achieve this. I'm still not sure why you wouldn't create the issue in the correct project and simply link the right Epic in your…

No relationship in standard Jira: Epic >> Story/Task >> Sub-task

please share one of your complete filters

Thanks Dirk and indeed that is a very good point and one that crossed my mind. Basically, is it reliable to simply consider a reporter to be an accepted customer based on an existing ticket. It would be great if we could have real profiles in Jira/JSM and it included customers. I would love to have a user profiles such…

i think it depends on more info to be honest. Note there are quite a few discussions in the Community this already so you might wish to search and get more input. With that said here is a basic guideline I live by. If your agents are going to be the same AND the types of requests (Request types) are largely the same then I…

you would need to be using Swimlanes by queries and add "... AND type != sub-task" to each swimlane you have defined.

Not sure what you mean by FAQ. You might search the documentation as NG is changing rapidly. I would not recommend deleting these issues. IMO, having the history of issues you decided not to do and why is valuable. I think marking them as done is fine TBH as being "done" doesn't necessarily mean "fixed" or "implemented"…

in sprint report click on view in navigator link then use the excel export link.

Were you using Classic projects I would say to use the Resolution for this. It appears you are using NG in which case you don't (yet) have Resolutions (JSWCLOUD-17499). You could create a drop down custom field in NG and select your resolution. As I recall there are challenges with multiple 'done category' statuses in NG…

you must ensure Obsolete status is in the far right done column of your board.

what you want to do is to have the first rule trigger on create and the second rule trigger off what the first rule does. In the second rule be sure to check the box to allow the rule to be triggered by other rules.

You are now able to manually remove Done issue from NG Kanban. you will see this option if you have issues in the Done column via the ellipses at top of Done column. Here is an article regarding this - Introducing-manual-board-clearing-for-your-next-gen-Kanban-board . You also have the ability to click a link at the bottom…

When you create the issue are you not creating in the project it belongs in? There isn’t a move function in Automation I think as that is complicated and subject to fail due to needing manual decisions. Your UC is odd to me in that you place epics in a separate project. Maybe I’m misunderstanding though. 

And select billing option

thanks for testing Daniel. seems consistent with what i was expecting.

i didn't do the forensics on this. however, after i offered similar it struck me that it may not work. I guess it comes down to how "updateddate" translates. For example, if I update an issue on Jan/1, Jan/2, Jan/3 and I use this query.... project = DEMO AND (updatedDate < 2021-01-2 OR updatedDate > 2021-01-2) does that…