multi-tenant configuration thinking?

[Ian Turner]

Hi,

i've used a couple of different JIRA deployments over the last few years and one thing i've struggled to understand is why customisations required in one project, or group of projects bleeds through into my own projects.

Whilst i get that inheritance of configuration can be good and may reduce the management overhead by having less configuration to support.  If we have a set of projects that are industry specific, health care for example, i don't want to see their terminology in my finance set of projects.

Is there something that describes the relationship of all the different schemas/schema types/screen schemes that would help partition the systems more logically?

thanks in advance for any advice

[Matt Doar]

The basic idea is to define a collection of Jira schemes and use that collection for a set of related Jira projects, i.e. all the health care-related projects. Don't let other Jira admins change those schemes without discussing it with you. Add a description with strong words to those schemes

[Ian Turner]

thanks @Matt Doar so is there any guidance / checklists on the schemes that need to be created?  I assume that the security model for admins isn't granular enough to allow owners at that level - hence the "strong words"?  from browsing the forums i've seen quite a few comments about performance implications of heavy tailoring, is that really a concern?  at what point does that kick in?

[Matt Doar]

Well, Chapters 3 and 4 of Practical Jira Administration (O'Reilly) are where I summarized this. Mail me at mdoar at my company name and I'll mail you the pdf of those two chapters