If one project holds multiple boards can we create diff. keys for those different board/subproject

[SUVARNA Dixit]

Project 123 holds 10 different small projects . 

"Project 123" is parent project ,for  child project/board can we create new key ? 

[John Funk]

Hi Suvarna,

There is no concept of Sub-projects in Jira. All projects are independent of each other when it comes to keys. You can have multiple boards associated with a project, or you can have a single board associated with multiple projects (though those projects are all equal in level).

You could use Epics to denote major chunks of work under a single project. That's probably what you are looking for. But you can't have different keys for the project in those. Nor would you need to. 

[Arnold]

My understanding of Jira's underlying mechanics is this:

Jira was the original software developed by Mike and Scott and released in 2002:  that was where 'issues' were stored in containers known as 'projects'

Later, a 3rd party developer developed the Scrum/Kanban Boards.  It was called Greenhopper.  Atlassian acquired them in 2009.  Eventually, this became known as "Jira Software" (it has the concept of "Epics" can contain "Issues" and other things like having the concept of "Sprints" in the "Scrum" boards, etc.

With both of the above two points in mind, I've always viewed the boards as separate things that interact with the underlying "Jira Core" Projects via the Filter contained in the Board's Configuration.

Board > Filter > Jira Project(s)

That seems to be how things work "under the hood".  The Board Software ("Jira Software") knows which issues to render in which Sprints - for example - by examining a Custom Field (created by Jira Software) called "Sprint" on the Project(s)' issues.

---

So I _think_ the premise of your question is wrong (although I am genuinely curious how a board can be 'located' in a Jira Project;  I noticed that came into the user interface and I couldn't figure out what that actually meant 'under the hood' - I still view Boards as external things, handled by Jira Software, and interacting with the Project(s) and their Issues in underlying Jira Core)

I.e. when you write "If one project holds multiple boards" that's not how I've visualised the mechanics (since 14 years now when I first got into Jira):  I've always viewed "A Board can interact with one or more Jira Projects"

---

With all that in mind, a Project only contains Issues and Project Settings.  It doesn't contain other Projects:  Projects are peers to each other, all contained in the overall container 'the Jira instance'.

---

I'd welcome any correction to my understanding above from anyone - maybe things have moved on since I first formed this view of 'what's going on inside the black box' some 12-14 years ago...

---

EDIT:  There are a couple of ways to 'subdivide' a Jira Project

"Components" (and a Jira Issue can be tagged against zero, one, or multiple Components) - they're like "Labels" except that whereas Labels are free-text / anyone can create them (which is their weakness: they're prone to typing mistakes), only a Project Admin can add/update/delete Components (although anyone can use them)

"Epics" - although just a regular 'Issue' in Jira Core, in Jira Software (the code that renders and handles the Scrum/Kanban Boards) it has the concept that an "Epic" can contain all other issuetypes (e.g. "Story", "Task", "Bug", whatever).

I use Epics for things that will eventually get 'done' (e.g. developing a new feature, or running a marketing campaign), and Components for 'themes':  themes will never get done but still need to be reported on:  examples are "Security", "Reporting", etc - they're never done, but are themes of the types of work a team will do.

I _have_ seen Labels being used to subdivide a Jira Project before:  I was placed on assignment by a consultancy and the client was using a single Jira Project for a programme of work which involved 100 people in three large groups.  My group / team's Backlog Items was all in the same Jira Project as everyone else's.  They had already started to use Labels to tag the items intended for them to deliver, so i created a Scrum Board (they were a Scrum Team) and added "...and labels = whatever..." to its Filter.  However, as mentioned above, there were data errors:  the official label was something like "AB-Feature" but work was tagged with things like "AB_Feature" (underscore instead of hyphen) and even typing errors in the word "Feature".  This is the weakness of Labels:  errors can creep in when people are rushing.