|
[
Permalink
| « Hide
]
gunter zeilinger added a comment - 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.
for ref from a SAC case
Hi, this is also an important issue for us.
Why this is high priority for us: Furthermore there is another bug that makes the priority even higher: Same thing here. I cannot stress enough the importance of this issue. And to play the angry customer: "I can't believe this issue has been open for 5 years now!"
I voted for this, we need this feature. I see that the custom URL workaround supports multiple pid=##### and component=##### in the URL, does it also support multiple versions?
Indeed, I've used this workaround to be able to have a list of issues for different project-versions.
it works perfectly fine! Mark & Stephane – What you are describing is not the same. By placing multiple PID, Component, Versions, etc. in the URL, you are essentially doing an "AND" query. AND queries have always been possible, even with the web interface the way it is presently.
What this ticket is really about (if I'm not mistaken) is the ability to do "OR" queries across different fields. Like, show me tickets that have "Affect Version = 1.2.3" OR "Fix Version = 1.2.3". John,
I think we were actually speaking about the same thing. http://gdps-prod/jiraRF1S/secure/IssueNavigator.jspa?refreshFilter=false&reset=update&show=View+%3E%3E&pid=10331&fixfor=13292&pid=10200&fixfor=13105&pid=10210&fixfor=13295&pid=10371&fixfor=13294&pid=10400&fixfor=13293&pid=10212&fixfor=13336&query=&summary=true&description=true&reporterSelect=&assigneeSelect=&created%3Aafter=&created%3Abefore=&created%3Aprevious=&created%3Anext=&updated%3Aafter=&updated%3Abefore=&updated%3Aprevious=&updated%3Anext=&duedate%3Aafter=&duedate%3Abefore=&duedate%3Aprevious=&duedate%3Anext=&customfield_10020=&customfield_10030=-1&customfield_10010=-1&customfield_10050=-1 This url looks for the issues for several couple of projects - versions. Am I right to say it is a mix of AND and OR? For what it's worth, my company is working around this issue as follows:
This allows us to filter across projects using the same version. It's not great but it allows us to get the data we need until Jeff, are you able to attach your jelly script to this issue? I'd like to use it (it would save me time) and I'm sure others might too.
Thanks in anticipation, Since my last visit to this one I've discovered a much better way of achieving this. I've written a "calculated custom field" plugin that creates a custom field that mirrors the fix version and shows up as a searchable field. Updates to fix versions immediately show up as updates to the custom field.
I'll publish details as soon as I can. The plugin would need a little generalisation if I were to publish the sources. Further development of Project Categories is a "nice to have". They seem like an afterthought, rather than a logical way to aggregate a set of projects.
However, I think rationalization of "Project Categories" is somewhat Orthogonal to this capability – the ability to do searches across multiple projects that have certain fields in common. When/if changes are made to Project Categories, then a Search Field that lets you pick any category or some set of categories, would then be icing on the cake. I've been prompted to attach the very simple plugin I wrote to get round this issue. See JiraSearchableReleasePlugin.zip. It's a Maven 2 module and will need some coding to make it useful to anyone else. (Suggestions for generalisation and configuration welcome.)
Notes: 1. Though set up to buid against Jira 3.13 libraries it will work properly on a range of Jira versions. 2. You'll need to set up http://maven.atlassian.com/public  as a repository in your settings.xml.3. This custom field is only really of any use in searches. The text name of your versions in different projects will have to be exactly the same for this to work. This plugin (as is) also allows a suffix "Approved" to be added, so for example "1.3 Approved" in one project willl be equal to "1.3" in another. To use: 1. Copy the built JAR to atlassian-jira/WEB-INF/lib. 2. Restart Jira. 3. Add a custom field. 4. Reindex the Jira database. When do you expect to release the version 4.0 with this new usefull feature?
My vote for getting this implemented for fix version and components, specially if the projects belong to the same project Category.
|
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
 |
|
New Feature
Open
Major
Filter on Versions and Components across Projects
