Jack Brickey Expert

the new view doesn't impact "feature functionality" but it may at times seem like it does. For example, presentation of issuetype in the new view vs. the old view. ;-)

Hi Celine, welcome to the Community. Why do you think you should have a field called Requirements? Where did you see/read about this? I have never seen (doesn't mean it doesn't exist in some scenarios) such by default. You can create a custom field for this if you like.

you have to love corner cases. looks like this was reported back in 2017, got very little interest expressed and ultimately closed. JSWCLOUD-16095 

Is this NG or Classic? If you take say COT-3 for example can you add say Stories under it? I wonder if this is simply an icon thing or is COT-3 (and others) truly Epics? I suspect we are dealing w/ a 'roadmap' issue here not an actual issue hierarchy. I see you are on Standard and while Premium allows for another level of…

yep. While "jia-servicedesk-users" could equate to actual billing details in a given instance, it isn't THE way to definitively assess. I like going to my Billing section personally as that is where the rubber hits the road.

hmmm, not sure how that could happen TBH. When you say you "changed Task issue type to Epic" can you explain how you did this specifically. 

I checked the documentation and did not find any reference to the Channel. However, you might be able to achieve your goal by using the Request type smart value if your request type for email is unique and not shared with the portal. That is what I do today.

AFAIK there is no system level tracking of usage. You would need to look at each addon and see if they have usage stats. I expect few do. Depending on the app you might be able to ferret out some data via JQL searches but that will be a stretch I suspect. 

Hi Vidya, welcome to the Community. I am not sure what you mean by “bau” Jira. What exactly are you trying to do here? Projects in Jira are all independent of each other and issues, permissions, workflows, notifications, etc can be unique between each. 

I assume these users are shown as inactive users under User Management. Is that correct? If so can you activate them. Assuming you don’t want them to have any application access just ensure that only Site Access is enabled. 

So do you want the assigned to always be the same as the reporter? If so and you are using Classic projects you could use a post function in the workflow for the create transition to copy the field value from reporter to the assignee. You could also consider automation. 

You would need to reach out to your admin about this. 

No that is not possible. You can however consider connecting Jira Cloud with Microsoft PowerBI or consider an Atlassian addon app that might offer a solution. Finally consider using Confluence as it is designed to integrate with Jira. 

Jim I don’t think I can help you here. This is something you need to assess with your team and Jira documentation. You might also google and review Atlassian’s Trust Center. cheers!

Hi Swheta, so not sure what adding statuses to a board has to do with multiple projects represented on a board. However, let’s see if we can get you straight. So are you using Classic projects a s boards? That is the first requirement here. Assuming so then please check the board settings and the columns view and see if…

DOH! I have seen it many times where people create a custom field with the same name as a system field. 

Those are new and part of the larger ITSM JSM. To my understanding these cannot be removed. 

Just re-enabled, tested and worked....

i will need to test on my end when i get a second.

you cannot as you are on Free instance. If you were on Standard or Premium Atlassian Support could assist.

Hi Asim, you might want to see this open suggestion - https://jira.atlassian.com/browse/JSDCLOUD-630 

i have had mine disabled for some time now (don't need it really) but it certainly was working as I recall. What does your log say?

that should do it i think

Hi Scott, do you really mean "linked" issues or do you mean issues that are associated to an Epic via the Epic Link. Just want to be clear as there is a difference. Here is what I have used to close the epic once all stories are done.

yep good call Bill. Also, i was poking around, just can't leave a puzzle alone. I am wondering if there is any way to capture the user that creates the branch. I found something about integrating GIT and you could require the users PAT (personal access token). But I'm in over my head as I just don't have GIT or Bitbucket…

Hi Jen, welcome to the Community. Have you tried and been unsuccessful? You can include fields in the detail view where the customer clicks on a specific issue and is taken to a screen w/ the details of that issue. As of now you cannot add them to the list view but there is some activity ongoing to all for some…

yes my suspicion here is in the "user who triggered the event". I'm thinking that the action of branching is not registering the user as the one who triggers. It would be interesting to see if you simply assigned directly to a user, e.g. yourself.

not following. I would think just the opposite - Portal for specific requests that can be assigned to individuals cleanly based upon the request type or some field selection. Emails for generic requests. Regardless you must employee Issue security if you want to control who can see specific issues. 

sure... * make sure the user(s) are licensed Jira users - admin - User management * create a group called say JSM-Collaborators and add the users to the group * in your JSM project go to project settings > permissions and add that group to the Browse permission and others, like Comment if desired. * you might wish to…

yes. saw that and is why I suggest (as a test) trying a different trigger. i certainly am able to set assignee based on trigger events. I suspect it is related to Bill's response but would test that out.