Regards,
Markus

Is there a possibility to link versions through different projects or to select multiple versions for an issue from different projects. Our company has a core-production methodology. So core features are implemented in core releases which are used by different applications.

Thanks,
Markus

If the aim is to have a 'Version' field across multiple projects, wouldn't it be better to make this a global custom field (hidden for some projects)?

So far this is a major headache in JIRA. We've addressed it by having a global Company Project field where we have a list of codenamed projects. Issues from each JIRA project get assigned to a given Company Project so that we can filter across the JIRA projects. Ugh!

The problems we run into here is that people will set the Company Project field, but not the Fix For Version or vice-versa and other people may miss out on certain issues depending on how they filter the data in jira. So we have to continuously ensure that any issue assigned to a Company Project is also assigned to the appropriate Fix For Version for the application it affects.

This is a tricky problem to address though. To be of any use, the
inter-project links need to be useable from within queries and possibly
reports.

We already have project categories in JIRA. If you could search for all
issues within a category, would that solve the problem?

Cheers,
Jeff

One thought I had was to extend your version management functionality to allow a specific version to be mapped to a value in global custom field. So I might have a global select field called 'Dev Project' with a list codenamed projects. Then under Version admin I could assign one of these versions to one of the Dev Projects. Any issue assigned to that version would cause the Dev Project field to be updated automatically as configured in the Version admin page. Filters could then filter off this global field. If you wanted to combine several JIRA projects under a single Dev Project you would just assign various versions from various projects to the same Dev Project in the Version admin pages.

I recently put a rather large post up on the JIRA forum related to this.

Actually, though I think it would be worth while to pursue a more complete and generic approach to managing Dev Projects and sub projects.

But the question again is, what JIRA functionality is affected by this grouping?

The idea with custom fields is a good one. JIRA custom fields need not actually store anything in a database. Their values can be determined entirely at runtime, based on other field values (so-called 'derived' custom fields). You could encode all the business rules into a 'Company Project' field type, whose value would become 'Everest' for issues whose fields met the conditions (in Product A, v3.2, etc). See the Custom Field Types tutorial at:

http://confluence.atlassian.com/display/JIRA/Customizing+Custom+Field+Types+Tutorial

and some examples of derived custom field types at:

http://confluence.atlassian.com/display/JIRAEXT/JIRA+Toolkit

Stepping back, I think what we really need is the ability to create filters across Project/Versions/Components (I've voted for and commented on some of those issues).

Ultimately, what I'd really like to do is assign a set of issues to a Company Project (codenamed project). These would be the issues that really define the project, mostly Features and Improvements. And further documentation for the project could be found in Confluence under the same Project codename. Then I'd like to filter on this Company Project field to get the list of issues for that project and assign those issues to particular project versions, could be across several Project/Versions (I can basically do this now). However, right now we also assign unrelated bugs to these Company Projects so that we can query on this global field to get the list of issues across multiple Project/Versions. This is the part I want to avoid.

If we could create filters across Project/Versions then I could still assign Features/Improvements that define a project to a specific Company Project, and I could simply assign these other bugs to appropriate project versions, maybe the next version to be released. BUT I could still see all the issues involved for particular cross-product release using the new filter.

Plus, using the global Company Project field, I could filter on a project's issues and lift them out of one version and reassign them to another version while leaving the unrelated bugs alone.

Don't know if this makes sense, but I think we're trying to implement alot of hacks to get around the fact that we can't filter across Product/Versions.