|
History
| Log In
|
|
|
|
[
Permlink
| « Hide
]
Lauri Siljam?ki - 01/Oct/02 09:10 PM
Also filtering across multiple projects and grouping by identical components would be nice for reporting purposes.
In addition, it would be very useful to have a filter capability that excludes specific projects ("find all but..."). One way to use this would be to include All projects, but exclude the Test project. It will be quicker to exclude a few projects than to select many projects.
Adding the ability to search across multiple project using a wizard.
Make search wizard to allow complex searching.
Jira needs the concept of "Project Group". When you want to use the data within Jira for reporting or management overview purposes then you will want to group projects by Business Function.
We currently use Jira within the web development area only. I will be proposing that we use Jira to manage the requests raised by systems Users within their business area. They will want to look at reports (based on filters) that relate to the projects within their area only and not those within the Web Development business area. If we then start to use Jira elsewhere within the business then we will need to group projects by new business. As all these issues are being resourced by the IT Services department then we would still like the option to have an overall view, without necessitating separate installations of the software. I can see that I could change the User permissions so that they can only read a particular set of projects. This would be acceptable for the Users within the Business areas. For the IT Services Users this would stop us from having a broader view of projects. We would possibly consider setting up an alternative user id? Even in this case, our default permissions currently are global read. (This is due to the fact that in the web development area they have been trying to encourage an open environment where Users are encouraged to log on and view the status of tasks.) Is there a way of setting up negative permissions so that we could set up specific Business Users to have read permission to a particular set of projects but not global read access? Using permisions still sounds messy. Is Jira not just missing some valuable data here relating to grouping of projects? I think it needs a piece of data such as "project group" or "business area". As a compromise, if the filter allowed a query on Project Description then we could set up meaningful project names. Perhaps another way of addressing this issue would be to aggregate saved filters into single reports. Then if you wanted to search certain components or versions across projects you simply create/save filters for each project and then combine them together in a single report.
multiple projects - using project category
Very disappointing that this issue will once again be ignored.
I agree.
It was set to 3.2 right? Why did this changed? They said they wanted to stay focused on core jira features, see email clip below. Funny though, every engineer that evaluated jira said the same thing right away, "I can't figure out how to select multiple projects to search in, how do I do that?" and I had to say, "You can't but they have that slated to get fixed in a upcoming version." ... I am still saying that several times a week to engineers that are asking when will they be able to filter multiple projects.
********************************************************************** We want to get the new core features in 3.2 polished and ready so we Nick Ok, thanks for the info.
FYI: this is not a nice-to-have for us. How are we supposed to get statistics/filtering on a group of projects? Currently, our managers use SQL queries to retrieve stats about a group of projects. Sorry about the slip on this again guys. We tried to get this into 3.2, but doing so properly simply involved too much hacking of the issue navigator that we had time to do right now. This issue will be properly addressed when we do a revamp on the issue navigator.
As a functioning workaround however, I've added a "Dummy Project Field" to the JIRA Toolkit. Through this custom field, you'll have access to fairly basic multi project filtering. You will not have access to versions & project specific custom fields, but for simple stats and filtering, this may be enough for many people. You can check it out at: http://confluence.atlassian.com/display/JIRAEXT/JIRA+Toolkit Please make sure you read the instructions correctly and apologies again for the slippages! Will this workaround work with version 3.0.2?
Kevin,
The short answer is no, but it would be possible to write your own custom field type that mimics what the "Dummy Project Field". Which is pretty much do nothing for anything apart from getValueFromIssue where it returns the projectId. Retrofit the searcher (the interface)), and the search template to the 3.0.3 code base and you should also be able to have your own multi-project searcher. For the searcher template, base your template on the 3.0.3 version of search-multiselect.vm. Cheers Mark C So the short answer is upgrade to 3.1.1 or better correct?
Kevin,
To get the workaround working without changes, you'd need to upgrade to JIRA 3.2 (out early next week) and install the JIRA Toolkit plugin. Cheers Mark C For what it is worth Bugzilla has this feature and it is an absolute necessity before i will be able to convince our mangement to move to JIRA no matter how many headaches we have with Bugzilla.
Thanks for the feedback - we are planning to implement this for JIRA 3.3 (next major release).
Anton What my be the expected release date of 3.3? The reason I ask is that if I implement the toolkit workaround, train everyone and they get used to it only to have the process to change in a month the users may get a little ticked since they aren't all that receptive to change.
Kevin,
I do not like mentioning dates that are not final - but as a rough estimate we are hoping to release mid July. Thanks, This is related to JRA-2837, if the projects view was sorted by project category, and the category names could be selected then this would be a good start.
This shouldn't be too hard, you could just ensure that selecting the category name activated a javascript that selected all the projects in that category, or somthing similar. So how we coming along on the implementation of this issue (and the projected release date mentioned by Anton)?
We're looking at a 3.3 release date around Friday 22nd of July at this stage.
All done! This will be released as part of JIRA 3.3
Does this allow us to also select the version for each project we select? Or does this change just make the Project field multiple select? In our case, we need to be able to filter across projects, but we also need to specify the versions or at least have it give results for the next versions on the respective roadmaps.
Our RoadMaps are basically populated with development project codenames like Klamath, Rogue, Sandy. These codenames are entered as project versions. So if we have several products being shipped together as a bundle they all belong to the same development project, say Klamath. We need to be able to filter all open issues across selected projects, version Klamath, to know the current state of our development project. Once we release, these versions get changed to actual version numbers which appear in the changelog. Any plans for allowing this? As of yet this has not been scheduled.
It can be tracked at: Please vote for this issuee and add yourself as a watcher. Cheers, |
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
 |
|
Improvement
Resolved
Minor
Filter on multiple projects
