How to configure limit number issues per component and who to disable multiple choice of component list

[Zyed TRIKI]

Hi all

i just read the documentation about defining component with jira (URL : https://confluence.atlassian.com/display/JIRA/Defining+a+Component#DefiningaComponent-default_assignee ) but i would know if there are a wa to set a limit number of issues by component and also how disable multiple select of component :

For example , we have Project named CLIENT and for this project we have three components : DEV,DESIGN and STD

Expect result that we needed is :

1. when user create new issue , *he can not select more than one component ( it means that he can choise only DEV or DESIGN or STD but not both of them or all of them )

2. in our organisation, we have these kind of restriction :

- The total number of opened (created) issues for the component DEV should not exceed 20 tickets(issues)

- The limit number for the componenent DESIGN should not exceed maximum 30 tickets

- For the component STD, this number is UNLIMITED

3. also additional question, how to configure a limit nulber of issue per project, in our case, we need for example to set maximum issues for the project CLIENT = only 50 issues

Could you please help us to define all these constraints

If there are some specific development, could you please give us more hints to allow us configuring this request.

thanks in advance for your help

Regards

[Nic Brough -Adaptavist-]

1. There are no limits on the number of issues a user can create, in any shape (component, issue type, summary, who they are, what colour their shirt is - doesn't matter)

2. To make "component" a single item, I'd do it in the core of Jira. In older versions, there's a dead simple tweak to the .vm file that renders the field to the users and you can simply change it from "multi select" to "single". I'm not sure that's quite as simple since v5, but I think I'd use that as a starting point.

For the numbering, you will need to do some coding to meet any/all of those needs, but you'll need to think about it, because there's no fields associated with components or users that you can hang anything off. (Fields in Jira belong to issues, so putting a field like "number of issues raised" on an issue is nonsense)

I'd use the active objects system to set up something that keeps track of the issues as they are raised and sets up a logical relationship with users and clients. I haven't dabbled in these yet, so I'm unqualified to tell you much, and will have to leave that to developer type people who are ahead of me here.