nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

Over 500 JIRA projects, one for each user?

Robert Galvin

My company has around 500 JIRA users. I was thinking of giving each person a project to track individual day to day task. The tasks would not relate to any project, but would be required for each person (i.e. training, promotion planningm etc.).

Does anyone see an issue with this? Is it a good idea? Would it slow down my server? Let me know what the pros and cons are.

Accepted answers

Udo Brand

What about one project, with a default security level (containing only Reporter). So only the Reporter would see his own tasks.

All comments

Jobin Kuruvilla [Adaptavist]

Not a good idea in my opinion. Number of project impacts performance and this requirement doesn't need a different project for every user either.

You can simply do this in a single project as the workflows, permissions all are likely to be same for all. You can just have different issuetypes for each item like training and then the users can create issues of that type in the project and assign to themselves. If one project is too less, create few based on organizational structure.

Robert Galvin

The number of projects impacts performance? What performance is impacted? Is this performance impact documented by Atlassian?

Robert Galvin

I looked at the following link:

https://confluence.atlassian.com/display/ATLAS/Scaling+JIRA

From what I read here, increasing the number of projects should have limited effect on performance. Let me know if I am missing something.

Udo Brand

What about one project, with a default security level (containing only Reporter). So only the Reporter would see his own tasks.

Robert Galvin

Excellent Idea! I also wanted people to have the ability to make components if needed. Any ideas on how that might work?

Udo Brand

Components can only be added by a user who have administer project permission. Not sure if it is a good idea to give this permission to all users. But you could use instead a label field (call it Component), where every user can enter his own labels.

Nic Brough -Adaptavist-

It's less the number of projects than the background work that will need doing. If you just increase the number of projects, then there won't be a huge impact on performance.

However, you will be limiting each project to a different user (or set of users). Jira will have to work out the permissions for users which can become a bit of an overhead if it's complicated. You certainly do not want to have one permission scheme per user/project, but there will still be an overhead if you go for a single permission scheme that uses roles to deal with one user.

Scaling Jira is not a simple linear thing. Your scheme may be absolutely fine, but I'm really not confident enough in that to tell you to proceed.

Nic Brough -Adaptavist-

I've done this with a "to do" list project, many times.

I'm not sure that "Reporter" permission will work here though - Jira sees that as meaning "anyone who can raise an issue in the project", not "the person who raised it". For that, you need to enable "reporter browse" permission. This also avoids the messing around with automatically setting security levels etc. See https://confluence.atlassian.com/display/JIRA/Current+Reporter+Browse+Project+Permission<br< a="">>

Norman Abramovitz

Can you explain why you need something like this? It is very raw to not be able to hang these types of items(trainging, promotions and planning) onto some sort anchor such as training week 2013-Sept-9, product markerting, 2014 year planning. It also seems out of the ordinary that no one else sees these items either if they are tracking business related items. What is the unspoken goal here?

Welcome!

It looks like you're new here. Sign in or register to get started.

Quick Links

Find more posts tagged with

jira

jira-administration