I’m going to perform a migration of data from one jira server to another – Do i need to migrate the users separately – or it is happening as part of the data migration?
Hi Naama, if there is internal directory – it would migrate users by itself. If external – you should better check the access from the new server.
Steph Truscott asked:
Is there a way or a plug in that will allow JIRA and Microsoft Outlook to sync and for example provide calendar reminders?
There’s actual add-on that should help – https://marketplace.atlassian.com/plugins/JOAI I’m not sure it can help you to provide calendar reminders. Perhaps, the better way is to integrate Google Drive with JIRA.
I would like to implement the following functionality in my JIRA installation: Each user has a supervisor who needs to be informed about the issues created in jira (by that user). For example when user ‘A’ creates an issue his/her supervisor should automatically receive an email with the issue details (just like the notification for ‘Issue Created’). The same applies for all issue notifications, emails should always be sent out to the supervisor as CC. What would you recommend, how do I go about implementing this ?
It seems that there is no easy way for it. It should be made a separate plugin, admin page with user association – supervisor and listener. Our team has made similar plugin with email notification,but in your case – it should be customized a bit.
In Agile it’s possible to add multiple fields to the detail view (see the screenshot onhttps://confluence.atlassian.com/display/AGILE/Configuring+the+Issue+Detail+View). Question:why would you want to add fields that are not defined in the underlying JIRA screen/field settings? In other words, an added field will be shown in the Agile interface (issue detail view), however in the first place it could/can not be entered when creating an issue, and then, it cannot be edited – because the field is not defined in the Create and Edit screen/field definitions. What is the logic behind this possibility? I would say it’s more logical to choose only fields that make sense according to the underlying (screen/field) settings in JIRA.
- It’s a lot of work to decide whether a field should really be there based on all the possible combinations, then you have to decide what to do if the field visibility is changed – e.g. if you remove field X from a screen, do you automatically remove it from the Agile view? What if there’s a mistake and you put it back? Expect it to automatically reappear in Agile?
- There are reasons to have access to fields that the user does not update. One really obvious example – bugzilla import id field. Not on create or edit screens, can’t be edited, just imported.
That’s all folks!