Does JIRA keep track of version and components changes (i.e. modification, deletion)? The reason is that if I give user an admin privilage to a Project to update either the version or component, I would like to know what has changed and who made the changes.
If JIRA has this capability, how do I enable and also see the change history? If not, any workaround?
Thanks for the help.
I'm not sure how detailed the logging is, but it doesn't look like there's a full audit trail out of the box. However if you're using 4.x then there's a plugin that allows you to log things a bit better: https://plugins.atlassian.com/plugin/details/43203
Related
is there a way to backup a JIRA project configuration and then restore?
The issue I have is that sometimes doing workflows changes I can break the whole configuration.
So, I'm looking for a way to easily rollback to the previous working version of the project configuration.
Please note that I cannot rollback the whole JIRA server as it will affect other projects.
We are using the latest version of the Jira Service Desk on premises.
Thanks,
Please, see full answer here.
You can't.
JIRA does a full export of everything, and you can import
the issues from one project from that. But that's it. If you need
single project backups with configuration, you'll need extra
functionality. This is exactly the case where I would reach for
Botron's tool -
https://marketplace.atlassian.com/plugins/com.botronsoft.jira.configurationmanager
Whenever you publish a change to a workflow, JIRA asks you if it has to save a copy of the original. If you do that, it should be easy to revert to a previous version. Still it gets cumbersome to manage lots of copies of a workflow and to understand what changed when.
If you want a bit more control, you can also export your workflow to xml and keep that somewhere. If you need to rollback, you can import from that xml again. For more details see the documentation here.
If you want even more control, then add-ons like Botron's configuration manager can indeed be useful.
Is there a way to reset or start over with the latest version TFS work item template? I do not care about any existing work item history.
Scenario: I have a TFS project that has code, but never used work items. The existing template is too old to use the automatic Configure Features wizard tool. It is ok to mess up any work item history.
Is this possible? Thank you!
Have a look at TFS-PowerTools
The built in Work Item Templates should override your existing ones. That might even work before updating, but i'd not recommend that try.
We had this trouble once too. A coworker fixed this after doing some kind of Troubleshooting guide. (Let me check tomorrow if i can find that one again)
Let me know if that helped!
Take a look at https://nkdagility.com/tfs-process-template-migration-script-updated/
It covers off what you need to do, and includes some PowerShell to help you.
I would like to get the issue list from Bugzilla and JIRA for an open-source project. For each issue, I'd like to collect the corresponding compilation units(for java projects, class/or interfaces files), which may relate to the issue.
Any idea on implementing this feature would be appreciated.
Many thanks!
For JIRA, there are some solutions out there you could use out of the box. See the documentation to integrate with source control for JIRA how to do it. This only works for some source control systems, you should which ones are supported. This gives you a list of change sets (e.g. for Subversion) for each issue.
Another approach could be to do it on your own through an interface to the source control system yourself. The following prerequisits have to be in place:
Your developers have the tools to add the information which issue was worked on by which commit on a per commit base.
You have rules that changes to the sources should all the time being done only for one issue at one time.
You are able to parse the additional information you will get from your version control system e.g. by a script or a program.
For Subversion and JIRA, it could work like that:
Ensure that all commits are only done if the Subversion commit message contains at least one JIRA ticket number. You may even ensure that by a pre-commit hook
Learn how to get the following information from the subversion log
The ticket IDs (by parsing the message) for each change set
The files that had changes for each change set
Collect for each file all tickets.
Show them in a format you like.
I think that this is not too useful, because ticket per class is too fine grained. Perhaps you should have a mapping of the files to modules, sub-projects, ... and collect tickets for them.
All solutions will be different depending on your selection of tools. JIRA and Subversion are here just examples :-)
The best way is to first integrate your issue tracking system with your source control. That means that whenever a developer commits a new change, it determines the set of issues related to this change. This linkage is managed by your issue tracking system and it can show you all the source files, resource files, config files that have changed in the context of an issue.
This info, will be available through the api of that issue tracking system as well.
We're using JIRA with SVN. We didn't have post-commit hooks working right, so some JIRA issues are missing some revisions.
Does anyone know of a way to add a revision to a JIRA issue after the fact?
The only way for the code to appear under "Source" tab in JIRA is to have a link in a commit comment in version control software. And if you forgot to add it - you can change the message manually. Although you'll have to reindex the instance for that to be applied...
How do you version in JIRA when your versions are like 4.8.{TFSBuild}.{TeamCity.Build}?
Do I simply create a 4.8 Version in Jira?
However what would I set the release date to?
The problem is that our versions are dynamically and created based on the build# from tfs and the Team City build#.
What is now the best way for me to create versions in Jira?
Only the Major. Minor is hardcoded for now and for every few bug fixes we upload the release to the live server.
Jira versions are primarily a planning tool (especially if you use Greenhopper aka Agile, where you can have a version hierarchy).
So that's different from a build. It may take a thousand builds to achieve the functionality planned for a "FixFor" version.
On the other hand, "Affects" versions are used to track in which build a particular bug was found. So it'll pay to rename the "current version" (when you mark it as Released) to the actual build, as Hugo suggests. And cleanup/close/move any outstanding issues at the same time.
I would suggest to name the upcoming version that doesn't have a fixed name yet something like "Next release".
When you actually do release that version then you can change the version name in Jira to reflect the correct name.
Using Jira For Project Management - Creating Versions
We use Jira for project management of daily task assignment and we like to have versions either by week or by month. This lets us assign work for a week and is very helpful with the Greenhopper plug in. Basically, you:
Open the project from "Projects"
On left side, click on "Versions"
We have version 4.4 so might be slightly different other Jira versions.