Project Design -- New bie..

[Raghavendra Maram]

Hi Experts,

I am newbie in using /configuring Atlassian JIRA however able to go through the help documantation and configured a project with all necessary custom fields, screen & workflows and its working as expected.

Now the next level is to drill down the project to have multiple teams / users use the same project with the below requirment. I would need inputs in building a better system. Thanks in Advance J

• Will have “XYZ” as a single Project and it will have only one Project Lead ( as standard ) who has the control on entire project as an ADMIN. – This is in place

• Project would have multiple groups like A1, B1, C1 etc.. – How to create ?

• Each group has X number of JIRA users - ?

• Each Group will have a Group Lead who should have access to his tasks (including team members of the group).

• Group Users – Users will have access only to the issues assigned to them as Assignee - ?

• If an Issue is been worked by multiple groups then the same issue is assigned to other group Lead as asignee via Sub Tasks –Sub tasks are in place

  On the the idea is to have number of groups and group leaders and users would create/change/complete their own issues and single issue can be used by multiple groups as subtasks

[Nic Brough -Adaptavist- · Accepted solution]

Groups don't have all those functions. They really are just collections of Jira user accounts, and have no strong relationships with projects - how you use them is up to you

So, taking your points

• (project lead stuff in place)
• You create groups in user maintenance. Then add the users you want into them
• As many or as few users as you want
• Nope, there's no concept of a group owner or lead
• Not sure what this has to do with groups. You can set project permissions to work off "current assignee" though. But you need to think carefully about what you mean by "access" - the permission schemes contain around 30 lines of different permissions you might grant
• Nothing to do here - there's no such thing as group lead

You might actually find it easier to skip the use of groups here and just do everything with roles in the projects - at least that way, the project lead can maintain the people who have "access" to their projects instead of a system admin having to mess around looking after groups.

[Raghavendra Maram]

Hi Nic, I am not familier with the use of Groups.. but my intention was to have each project sub divided into multiple other teams and each team has a owner with set of users in it.. no other teams should be able to see issues assigned other than the one they are part of the group. I read somewhere suggesting to use component lead.. does that works for my case ?

[Nic Brough -Adaptavist-]

You need to separate out "groups" from "projects" in your head.

• A group is a collection of users. A user can be in none, one or many groups (which instantly breaks your access model because everyone is in the "can log in" group and hence can see everyone else's issues). There's nothing in groups beyond "a collection of users". That's all they do
• A project is a collection of issues with a set of configurations to make them behave in a specific way.

They have no direct relationship, you need to define that.

• The best way to do it for you is probably to define a single permission scheme that lists the access a ROLE should have.
• Then, group your users together into the groups they need to be in
• Then add the groups to the roles in each separate project
• (Or, don't use groups, and just put people straight into the roles)
• This will separate your users by project.

[Raghavendra Maram]

Hi Nic, As I am new to the tool I may sound layman in asking questions..

However

I wanted to have only one project ( basically I wanted to use each client as a project) So each client has multiple teams working with own set of tasks, as you said abouve I have created a single permission scheme.. my question is how do i differantiate the tasks of each team and no other team member should have access to other teams tasks.

Please suggest

[Nic Brough -Adaptavist-]

Ok, so how are you going to tag the issues to mark them as belonging to a team (or set of teams)?

You simply can't segregate issues up without some data on them to allow you to do it. The standard approach is to drop them into projects, but you need something else.

There are ways to separate them within projects, but before we can launch into that, we really need to know how you are planning to identify the issues as belonging to or to be worked on by a team.

[Raghavendra Maram]

Thanks Nic, Post your inputs and my analysis.. i have moved out of having entire concept of having only project and multiple leads.. and started creating each group/set of users into individual project and have prject lead for every project for better control.. Looking into options to have control over permissions to view isssues based on authorizations.. wanted to have project lead should be able to view / edit any issue and team memebr should be able to see / edit only their own issues.. please suggest.

Thanks

[Nic Brough -Adaptavist-]

Look at the permission scheme first, then have a re-read of the previous answer and comments here - it's all covered there!

[Raghavendra Maram]

Its done thnx..