|
History
| Log In
|
|
|
|
[
Permlink
| « Hide
]
gunter zeilinger - 10/Feb/04 03:08 AM
Updating due dates according release date of versions enables to use Due Date filter to find issues of several projects which are scheduled for versions with same release date
It would also be nice to be able to search Components across projects. We have several projects that share alot of code in a set of common libraries. These projects share the same Components. When I'm fixing issues in Project A for Component X, it would be nice to search across the other projects for any other issues against Component X to make sure I pick up anything critical.
What we REALLY need is a way to filter across projects on different versions. We have several projects that are released as standalone products. However, they are also bundled up and shipped as a bundled product or suite. Now we may be working on Suite 4.0 which consists of ProjectA v4.5, ProjectB v8.1.1 and ProjectC v7.3. We want to create a filter that would filter across the specific Fix For versions of these three products. Then we could call the filter Suite 4.0 and it would give us the stats we need. This capability would even be more valuable now that you have portlets that can give you stats based on a filter.
Right now we have a custom field called Bundled products that we use to generate this kind of filter, but users are always forgetting to set the either the Bundled Products field or the Fix For version or the choose the wrong Fix For version to go along with the selected Bundled Products. It just not an ideal solution. I've entered this comment on several other issues including We have multiple projects going on, but we like to restrict roll-ins to bi-weekly windows. That means many projects aim at the same milestone. The best way I have seen to do that in Jira is to have each project keep a list of "versions" which are aligned with the global milestones.
But I can't find all the issues across the projects which are rolling in on a milestone. Possibly we can build some sort of custom report, but I would certainly prefer to be able to just create a filter that does this. I add my vote to this issue - ability to filter across projects based on named version is very important.
In real life the model is many-2-many between proejct-version-component entities. We have been struggling with this issue as well to the point of looking for other tools which do this better. The way we deal with it at this point is an SQL query to generate the list for a release and we dump it into Confluence manually. Here is the query we have been using it depends on similar version names. Enjoy!
SELECT '|' , VNAME Milestone, '|' , I.PKEY KEY, '|' , I.REPORTER, '|' , I.ASSIGNEE, '|' , I would actually like to do something different than a simple 'where version = 1.0' kind of filtering. I would like to be able to add tags to versions and then for example tag Project A v1.0 and Project B v1.5 both with 'Release Service FooBar' and then filter on that.
That way it is very easy to create big lists of issues for a specific release that consists of several projects with different version numbers. Quick comment: I do totally agree with Stefan. I have the case of "packages" which involve different project with different version number.
Stefan's solution would be fantastic if implemented ! I addressed this need differently while waiting for the improvement: I added a custom text field called "Shared Fix Versions" and a workflow function that copies the issue fix versions to the "Shared Fix Versions" field. Then, it makes the life much easier to filter on the custom field instead of the fix versions when targetting multiple projects.
Vince In my company, people are working on several projects, and want filters across these projects, showing only issues on specific versions. However, the only version specifications we need are the special ones: "Any", "No Fix Version", "Unreleased Versions" and "Released Versions" for both fix version and affected version.
This way, we can create shared filters showing "all issues to retest", or "all issues to fix" across multiple projects. Based on what my company is looking for and Kevin's comment above, it seems like what is needed is the concept of a Product.
Products (or suites) are composed of several projects. A project may be included in several products. Each product version is linked to specific versions of each of its projects. The best path that I can see to this is by expanding the product category feature. Allow a project to be in multiple project categories, add versions to categories, and then link category versions to project versions. As far as we can tell the workarounds are less than ideal:
Let me propose an idea - having "component scheme" and assigning that scheme to project would make possible 'sharing' components across various projects and maybe using schema component for issue filtering?
I agree to Gavin's conclusion. For our product organization we need to compose a product belonging to a "product line" from components that are managed independently from each other in separate projects.
As a first step having a text search field for versions when selecting multiple projects in Search would be very helpful. In the long run introducing a product/product line concept would be the smart solution. For me, I think having the ability to specify more than 1 condition for a filter would do the trick. I want to see ALL issues created in the last week, regardless of current status, AND any issues with an "open" status regardless of when they were created, for instance. Right now, I have two separate filters for these and have to merge them outside of Jira. Would be nice to AND / OR several searches together and have them appear in a single filter.
Any idea when we could expect this functionality in JIRA ?
Our company has been long awaiting this New Feature, and i know of some other company's using JIRA are really waiting for it aswell. The ability to create more flexible filters could really enhance the reporting functionality and information that JIRA portlets would put out aswell. This offcourse goes hand in hand with the abillity to create versions per components. Over 4 years as a Major issue and still unresolved? Hey Atlassian, what's getting in the way of you taking action on this?
In some cases, a possible work around this limitation could be to create a custom URL in the following way:
The URL constructed in this way should return all open issues in the Documentation components for both projects, which can be saved(filter) for further use. I agree with John on this one JIRA-1560 has defenatly got my vote.
Strange thing is, that all the issues i seem to vote for lately have been created 4+ years ago. I also agree that Stefans idea would solve our main problems.
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
 |
|
New Feature
Open
Major
Filter on Versions and Components across Projects
