How do you handle shared components in your JIRA projects?

[Evelin]

Atlassian does not publish a best practise guide for this question (I asked for it, but it was rejected). I wonder how other admins handle the situation that software products share some components.

How do you organize your projects? Do you create one and the same component several times? Or do you keep them all in one JIRA project?

At the moment, I think the best way is to create shared components several times, per project, but I don't know if I have overlooked some trapdoors. I'm aware that

• it is much administration overhead if you are not allowed to buy plugins
• when querying JIRA for components, you need to include all projects
• charts with component filter will not sum-up the issues but list the component n times which makes the charts unconvenient to read.

Thanks for your attention

[Nic Brough -Adaptavist-]

Use the components locally in projects, and then add a global custom field to cover the shared ones.

[Evelin]

Nic, Thanks for your quick reply. Amazing!
I already though about this, and I was not convinced. There are disadvantages, for instance will some pre-build reports in the projects not return the correct number of issues, and the component view of the projects is incomplete. Also, a custom field is more inconvenient to manage because you need to re-index. Assigning issues to Component Lead will not work for all issues, and the same for queries that include ComponentsLeadByUser.

The more shared components you have, the more data will be excluded from the reports. Usability in general will be affected.

[Nic Brough -Adaptavist-]

The standard component reports will continue to report on project components, but as you're not using them for the cross-project stuff, that's fine.  You're going to need to create cross-project reporting reports (saved filters and dashboards are your friends for this)

You do no need to re-index a custom field unless you're making certain structural changes to where it's used.  This field should be set to be globally available - all projects and issue types, so you'll need to index once to make it fully searchable (with or without any data in it) and that's it, you don't need to index anything again.

You won't have the component lead functionality on a simple global component field, no, but then it wouldn't work globally anyway - a lead might not even be assignable in projects.

I don't understand your last paragraph at all.  Adding a new field will give you cross-project visibility of a genuinely shared component that can be reported on like any other field.  It will affect usability - it'll make it easier to work with global components!

[Evelin]

Thanks for the hint about the re-index, and I will also think about your other suggestions.

Regarding the usability: User will need to fill in two fields, component and global component. So far I didn't ask them but I guess they are not too pleased.

[Nic Brough -Adaptavist-]

You could just drop the need for components completely.  The places I've been that use global components re-use the field for something local to the project instead, but some don't need that and just drop it.