Hernan Halabi Community Champion

I would create an agile board with all the tickets assigned to me to do this. On an agile board you can see whatever you like, maybe the filter criteria is a bit more complex than just assigned to me but that's the logic behind. Later you might want to see each project as a swimline to easily see what belongs where

No worries, jira can be messy at first. Roles are shared across all projects, try to use generic names on them to reuse them better. Ideally, you should have a single permission scheme that you would apply into any project you create, the more you reuse, the better 

If your setup is correct you can restrict users to see just the projects they need with a proper permission scheme, and restrict the issues they see within that project by using a security scheme. Your permission scheme should be based on roles and you should worry about adding the people to the roles they are supposed to…

I'll agree on that, as I mentioned on my first answer, technically yes you can do this, but it's not the best tool for it. Even though you can customize it to make it work, it's too complicated and not very worth it to do all this setup to get that sign off.

Based on your input I would keep with the plan to create the ticket via rest and have some front end to show the the customer rather than take them to Jira to sign. You can do kind of a mix of my original proposal. Instead the agent providing the document, it gets created from this front-end I mention. If changes come in…

No one that comes to mind at this point, the one that knew isn't supported for JSD. What I don't get is how the process works. Why a customer would create a ticket to agree terms? Sounds a better option to have the standard agreement somewhere online, maybe a Google form, and as they submit it, create a ticket via rest…

Might not be the best tool, but yes. The way I see it... Agents add all the info in the description field. On the next status they add the guy who needs to sign as approvers. That gives you flexibility for he back and forth. You could allow to edit the field only on transitions and each one requires a new approval. You…

Hello Jai, you confuse me a bit with the "resolution status" thing so to clarify. The status is one thing and usually is open, in progress, done among others and this one doesn't have impact on what the customer see on the customer portal. You change this one by transitioning the ticket The resolution is another field…

Agents are in the jira service desk team role within that project?

Notification scheme looks good enough, it should list the role where you have your agents rather than a group. Solution would be more scalable. Try removing any agent from the customer tab that you sent.

may I ask for some print screens with the notification scheme assigned to the project as well as project roles to see that config? also show the customers tab where the organizations are supposed to be, your last comment leads that is not the case but the more the better :)

As stated on the other answer, when the agent is a customer as well because belongs to the same organization than the one who submitted the ticket, it confuses jira and notifications might not go as expected. Make sure that those users don't belong to the same organization in JSD

is the support team part of an organization? see the following question similar to what you mention 

I've setup in the past permissions in the past with Permission schemes based on roles, same as notifications. Then managed access based on groups added to those roles, and in some cases issue security levels to restrict projects even more. I made this with my team on an instance with more than 300.000 users and 3500…

Nothing else that I can imagine at this point based on the information provided.sorry about that 

Since you are in cloud you can't see the logs to see what's happening, sounds like you will need to contact atlassian support to help you troubleshoot this. They might be able see something from their end.

no, you can't do it as you describe it. The compromise solution: Allow only to edit that field on a transition (from one status to the same status) and as part of the transition add a validator that a comment is added as well. Won't end being the prettiest workflow at all, specially if you are going to do allow this type…

What feature are you looking for? A checklist as suggested by @Ste Wright ? Or just a simple way to keep track of simple tasks? In the past we made a simple project just with tasks and subtasks and a very basic workflow. We named it my personal tasks and issue security by default to allow only the reporter and assignee to…

It's odd that he doesn't get notifications from other agents creating tickets, does this happen from both the customer portal and jira agents view? About the notifications he doesn't get for the changes he does, that's always like that by default, he needs to edit his profile and change the setting that suggests to notify…

Thanks but no need to, as I mentioned, I already used your app.

Vitor, you can't create bar chart reports on text type custom fields, at least not in a native way. You might be able to do it using eazybi check this documentation as a start, you can always contact their support team, they answer pretty fast

Hi, we have done things like that in the past with the help of these addons https://marketplace.atlassian.com/apps/1215199/backbone-issue-sync-for-jira?hosting=cloud&tab=overview https://marketplace.atlassian.com/apps/1213645/exalate-jira-issue-sync-more?hosting=cloud&tab=overview If I recall correctly, the first one is…

as mentioned, check the ticket history, if the ticket would have been pulled from sprint 4.2 to 4.3, then it wouldn't be considered as a scope change as the report shows. What I read from what I see, is that ticket was added to 4.3 after the sprint started. Maybe someone reopened it and decided to add it no that sprint in…

Within the ticket check the history tab, last image shows that the ticket got added after the sprint started (scope change) and then resolved. Maybe checking there will help you identify who did it and therefore... why.

can you provide some screenshots? might help to understand the issue. I would say, one of the ticket and one for each report

yes, you will be able to run reports for sure with those.

does the ticket have a resolution in place? that report works based on ticket resolution rather than ticket status.

Hello, you can't do any of those things but you could use a multiselect custom field instead, that you only jira admins can add options to it, you can limit the options to an specific project and users can only pick what is in place.

You should change a bit those steps for better reuse. on item 4 rather than add the people you should add the group you created into a certain role. Then step 7 instead of notifying per group , you pick the role where you added the group from step 4. That way you can use the same scheme on another project, you just change…

El comportamiento debería ser igual en ambos casos. No hay de dónde configurar eso. Será alguna funcionalidad faltante de la aplicación lamentablemente.