Gezim Shehu [Communardo] Community Champion

Hi, Though I disagree with the "categorization" by summary, the actual automatic summary is a good approach. You can surely do it in a lot of ways, but most propably in a post function during create transition. You need to add a custom script post function into the desired workflow (custom script post function - part of…

By default I think no. In Service Desk Portal, if you have Extension for Service Desk add-on, it has a functionality to show linked issues and selected fields for those issues. In JIRA Software, maybe a script field would be the easiest choice. You would need Script Runner (my suggestion only) for that. Script Field would…

In the portal you have this option: Also if everything is configured as default, and an initial email is sent to the user saying that: "We got your request....." You also have an email clickable link to do the same thing, disable notifications for that request.

Yes there is. The filter of the board can be modified to accompany your requirements, or better the board sub-filter can be specified. JQL simply would be something like assignee = currentUser() or reporter = currentUser() Ps: Maybe specify Board in the summary/title, I though this was for issue security level :)

Hi Craig & Everyone reading this. I'm following Craig's template: Born and raised in Tirana, Albania * Started my career in 2013, while in University, independent work, mostly web-development. (Same time worked as an audio engineer)* ~3 years * Beginner's compo :P (PHP + Javascript + MySQL db) * In 2016, started an…

Maybe it's just a matter of filtering issues? Status?

Hmm, I cannot tell 100%, but if I understood it correctly, this is what I suggest: Epic Issue workflow , transition to "desired status goes here". This transition contains post function to create linked issue.

Hi, Sorry cannot seem to follow you. If you want Epic Issue to transition to 1 status, why exactly is the post function in the Linked Issue workflow?

LMAO so sorry. Didn't really see the labels, as I usually have them defined in my feed (not today though :) )

EDIT ->> unrelated to question. This only applies to JIRA DB SELECT DISTINCT p.pname,p.pkey ,i.issuenum,cg.issueid ,cg.ID ,cg.AUTHOR,cg.CREATED ,ci.FIELDTYPE,ci.FIELD ,ci.OLDVALUE,ci.OLDSTRING ,ci.NEWVALUE,ci.NEWSTRING FROM changegroup cg INNER JOIN jiraissue i on cg.issueid = i.id INNER JOIN project p on i.project = p.id…

aaaaah. That explains it. Thanks, Cheers

Hi guys, @Nic Brough -Adaptavist- I'm curious how does Script Runner's built in function do it? Just from the technical view :)

Hi, I really don't think JIRA should have the info for this. Meaning that it can't know by itself. If you have any other way of knowing, maybe network traffic or smth similar, you could then store it. Or even ask your customer with a simple field.

I would suggest changing the workflow for that issue type, and add an impossible condition. Or if same workflow is used, implement a validator only if the issue type != blocked_issue_type

Got my new badge :)

Glad to help

Application Access is OK. Though in case of multiple, well even few, users - my suggestion is to go by groups, example JIRA_Users_Dep1 JIRA_Users_Dep2 ,etc and give Application Access to that group. What I'm saying is that you should not configure permissions based on jira-users-group. jira-users-group should not be able…

That is a different case, but easily solvable. First of all setting up permissions for Application Access Groups (i.e jira-users-group), imo is definitely wrong. Please revise that. Second, for you exact scenario, go to JIRA -> Applications -> Applications Access and add "New_Group" under JIRA Software or Core, depending…

Try adding a permission schema based on project roles. This can be applicable across different projects. Create a new user group and add the members you want. Let's say Role "Core Team" Configure permission schema that "Core Team" has: * Browse Issues Permission * Assign Issue Permission * Create Issues Permission *…

Great Advice. These are the "unwritten" rules :P

That would have escalated quickly @Herman Xiao :P

Still though, the Customer Portal is an issue, as ultimately customers and approvers require the full history to be present.

Hi @Aron Gombas _Midori_, That sounds a great option, though not applicable for my situation. I am leaning more towards an "backup" instance where : 1-Either all the issues are stored 2-After successfully testing the solution, only export backups from Production and use this as a restore instance for audit/investigation…

Hi @Sloan N_ B_, Yeah it's definitely gonna need an offline archive sometime soon. Unfortunately I too haven't found any solution or best practice for this. Loading project by export all instance and importing one project only at an offsite backup may be a valid option, but still not optimal. Cheers

Seems like today is the day of no details lol

If you don't provide any additional detail, I'm afraid no one can help. What JIRA version? Instance , Cloud? Is the slow down specific to one behavior, or all usage? Any changes recently? What's showing in the logs? etc.

Good Advice. Known issues and workarounds should help. I feel relieved that no database change is in our plans though :). We've already upgraded our PostgreSQL version prior to any software upgrades. Thanks

Good point. I also tried out the new cloud UI for JIRA and Confluence. At first I though maybe it was a one off thing, when you were just used to an old "way" of doing things and have difficulties embracing changes at first. Well I tried it near a whole week and couldn't get around it. (joke's on me as I'm an admin lol -…

I am giving this a try, currently on 6.0.6. Will update

Hi, I didn't went through all of the releases, yet. I will. After going through all I think if there are >1 major upgrades between the deltas I guess we'll have to split. Else, I think we can try and pull it off at once :) Do you have anything in mind that could block this? Thanks