Whenever there is a new release of an APK, I create a release version under the project
releases option in JIRA. And now, when creating an issue, I put the newly created version
in the affectedVersion field.
But now, when I have to search for all the issues in this version, I have to write a JQL
like project = "BA" and affectedVersion=2.0-uat-2 order BY created DESC
Is there a way to avoid writing this JQL and instead have a dropdown for affectedVersion
which shows all the versions. This way, there will not be any need to write a JQL manually
Related
We have been keeping an update log in a g-doc and maintaining it manually outside of Jira. The document keeps track of every release and the change notes. Is there a way to automate this in Jira?
Update log example:
7.16.395
• Fix for error when applying stock from schedule tree.
7.16.394
• Part configurations update when templates are selected.
7.16.393
• Fix for subbing multiple order BOM items at once on the Part>Usage tab.
• Fix for inventory counts not syncing.
• Fix for marking order items complete.
• Fixes for pick list quantity calculations and prioritization.
• Template changes updated to part configurations with the 'Sync w/ templates'
you can use Jira Automation for it.
Create an automation rule which will automatically trigger along with a new release.
to do so,
goto project setting
select Automation
Create a new Rule
Select "Release new Version" in the When section
Use lookup issue action and add JQL filters like project='xyz' and fixVersion= '{{release.name}}' .....
finally select a notification action like slack/email or create a wiki page
Tempalte for notification action :
{{#lookupIssues}}
> <{{url}} | {{key}}> : {{summary}}
{{/}}
Let us know if it helps
We have JIRA issues with the following fields:
Affects version - version where issue is noticed
Target version - version in which we want to fix the issue
Fix version - version where issue is really fixed
The release planning is based on the fix version, I suppose per default. How could it be changed to use the target version? We set the fix version when closing an issue, so it is not at all appropriate for the planning.
"Affects version" and "Fix version" are system fields in JIRA and various screens are based on them. This is logic that you cannot change.
The "Target version" is not a default JIRA field, so it must have been added as a custom field on your instance.
Instead of trying to change the concept of a "Fix version" you're better of using it as it is intended by JIRA and customising your own logic with custom fields that you add yourself. Otherwise screens like JIRA's "Releases" view will not behave as expected.
So you should use the "Fix version" field to plan the target release and update it with the appropriate version if the actual release changes. For any other kind of version info that you like, introduce your own fields.
In the "Releases" view you can click on "View in Issue Navigator" on the right side:
This will show the JQL that is used by that view and it will show something like:
project = 12421 AND fixVersion = 17740 ORDER BY priority DESC, key ASC
This is hardcoded and I don't know of a way to customise this.
I have a Mantis bug tracker installed that we use for all of our products. One product goes through a rapid development cycle and each new build gets a new version number (the build number is incremented). Since our QA has to report all bugs they found for the build that introduced the bug, we also have to add a new version number to Mantis every time a new build is made. Because of this, the list of version numbers under Manage->Manage Projects->Project name is now very long.
I just tried to delete one of the very old version numbers but that removes that number from all issues that referred to it. (Makes sense from a DB design point-of-view.)
Is there a way to shorten the version list without affecting the issues? The very old version number we have will never be used again but I want the old issues intact. I did a bunch of Google searches but I keep getting flooded with unrelated results.
Did you try to set the obsolete attribute of version ?
As said in the admin guide :
Each project can have several versions, which are marked with attributes like released and obsolete.
and :
Once a version is marked as obsolete, it is now longer included in the change log.
See also these issues :
Obsolete versions not selectable as filter in `View Issues'
Versions marked as obsolete appear on change log page
If I understand you properly, what you'd like is a way to filter the versions displayed in the Manage Projects page.
This cannot be done in current version of MantisBT (1.2.14), and would require a change in the code. I suggest you open a feature request on our tracker. If you end up implementing the feature, then submit it as a pull request on our Github repository.
I'm copying bug items from one tfs project to another.
I'm using the copy method to create the bug in the new project, but the bug is not copied with the history details (revisions).
I need the history field to see all changes that were made and also free text that we're adding when changing States.
I tried going over each Revision item but there is no way to add the revision item to the new work item, and i can't find a way to retrieve the data I need from the Revision object.
Does anyone know how to get the information?
There is a project on Visual Studio Gallery: http://visualstudiogallery.msdn.microsoft.com/cd89c5d3-4816-4f22-b04e-a397cc606be6
I have not tried this, but maybe it can be helpful.
You can use the TFS Integration Platform to move or copy projects (including work items) from one TFS project to another, or one server to another. I have not tried moving just work items, though.
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.