|
History
| Log In
|
|
|
|
[
Permlink
| « Hide
]
Barry Collins - 15/Nov/04 01:59 AM
It would also be very useful if subtasks could also be included either on a per project or per Issue type basis.
Not being able to select issue types active for each project severely limits the use of the new cool form customization tools in Jira 3. We'd like to have separate different issue forms for separate departments which do very different type of work and having to have every issue name visible in all projects makes this a lot harder. For example, one form type might be "Marketing material order" with a lot of detail of the material requested while other issue might be "Customer support request" or "New feature request" which obviously would detail very different things and making the person issuing the CS Request see the Material Order issue type is really weird.
Pretty much dissapointed this issue has not yet been scheduled for a release. We're in dire need of the ability to assign issue types to specific projects only!
I concur - this feature would be great to get soon!!
Come on Atlassian, with this request having the most number of votes, when do you propose to introduce this much wanted improvement.
Hi, I don't know why the following linked tickets are opened with priority "Major"
and the parent Jira-1602 ticket has priority minor
Hi,
The priority of this issue has been updated to 'Critical'. Thank you for Regards, Any word on when this might get assigned to a release version? I'm working on a hack to scope issue types to a project, but would love to avoid deploying a hack!
I'll have to also add myself and my organization to the list of people waiting for this feature. We are looking into possibly using Jira as a Change Management system as well as a Bug Tracking system. The ability to customize fields for different issue types is great, but making all issue types visible to all projects kind of defeats this ability. Every issue type is not necessarily relevant to every project.
Also, limiting who sees certain issues is great but there is also a need to limit who creates what issue types. So associating permissions to issue types would also be nice. It won't be in 3.2, but as a popular issue there is a good chance of it
appearing in 3.3 or 3.4. Cheers, Is there a schedule for the release of 3.1?
I guess potential 3.3 or 3.4 inclusion means the feature might not make it during 2005? Doesn't make me very happy but then you're the developers and do make the call on the schedules.
Guys, are you kidding? Not even 3.2? Considering there's no evidence for 3.1 yet?
We are waiting for it for almost 2 YEARS already! This would be a great addition to Jira. Please reconsider for faster implementation schedule. The votes should support faster implementation.
I've got a workaround for this.
I've created an "unassigned type" workflow. I put and administrator permission on the "create". For a project, I link this workflow with unasigned type. A person that is not an administrator will effectively see those unassigned issue type when create, but it will generate an exception if he tries to create those types. Hope to see this resolved soon We would like to see Issue settings fields settable on the project level. We are currently evaluating and this will affect our purchase decision.
We are also evaluating JIRA (after becoming a Confluence customer) and this is the first thing that became an issue for us. Everything else in JIRA seems great but this one simple issue has a dramatic influence on the overall effectiveness of JIRA for our purposes.
Hello,
We are now pushing JIRA into the bug tracking mode. Still using it in help desk mode as well. I'll have to write a GUI hack in order to disable issue types according selected projects. No other choice. I am looking forward this possibility to have issue types a function of the projects. Regards Gilles Hi Atlassians,
i think you are right in the middle of testing and releasing 3.1. But as so many people are very keen on this feature, what do you think about postponing the release and to let get this issue into 3.1. I think nobody waiting for this feature will be mad about you, if you postpone 3.1 for some weeks, or whatever time it will take to implement this feature. Just an idea. Cheers, Ditto for us. Would love to see you release even an unsupported beta update that would let us try out and debug a solution for this.
If you were to implement: Per Project - Issue types Then Jira could easily dominate the market. Just wanted to add another voice to the long list of people who would find this feature asstoundingly useful
Here is another idea:
What about using the workflow-scheme to define, which issue-types are available for the project? If an issue-type doesn't get a workflow assigned in a workflow-scheme, its not available in the project. Therefore jira would have to allow issue types, whith no workflow attached to it. How about this? Is there any meaning voting for issues?
It does not seem to change schedule plans anyway. I don't know the underlying class and database structure of JIRA in detail, but what is the problem to implement this? Are big changes to make to implement this?
a) A quick win would be when in step 1 of "Create Issue" the issue types are filtered, when the project is selected by the user. Likewise the onchange="javascript:refreshProjectFilter()" javascript on the "Find Issues" page. b) In the "Edit Issue" page the issue type can be pre filtered, hence this would be no problem. c) The "Move Issue" page contains the new issue type, hence this would be no problem by moving an issue to another project d) A administration page for project specific issue types should be no problem for the Atlassians. Do we have any problem with different workflows? Lars,
It is not overly complicated to implement, but not trivial either. Eg. when moving issues across projects, the issue type may be forced to change, implying a workflow change. Jeff,
It doesn't seem to complicate the scheme. I.e. you can now change the issue type when moving the issue. Jeff,
Fully dressed solution can eat huge amount of time, we know that. JIRA has many small pearls so tracing all dependencies and redesign behavior may be not trivial. Nevertheless it would be very appreciated if you could implement even smallest feature set in this area (it goes 80/20 rule, I guess). For me the first stage is to built in a map of available "issue type" for a project even managed only by JIRA administrator. Other stages can be referred to other future releases. best regards, Hi,
We have planned to implement this feature for a while, and took the largest step in the right direction in JIRA 3.2. The field subsystem has been completely rewritten such that it is much simpler now to restrict issue types for projects and ensure that moving, searching and bulk-editing issues will not break. We originally planned to implement this for JIRA 3.3, however hit another problem: Due to this reason we will implement Bulk Move - Thanks, if anyone has written code (even hackish code) to limit issue types by project please attach it to this issue - the typical case (from my perspective) is not changing issue types per project on existing issues but being able to create new issue types and limiting visibility to a single project. Atlassian is concerned with more of the ongoing support problems with having this functionality - but as far I'm concerned just having the drop down on create issue limited by project is enough to start with. That's all 80% of the users would ever use anyway. No one bulk edits because it creates such an email flurry and when moving issues I'd change the issue type to one that's common across all projects. hackish, but functional.
Great ... we have a possible fix version ....
Thanks for the information. Regards Sven Hi all,
while waiting for the official fix, I've found a simple workaround for this problem :
That way, a user that chooses the wrong Issue Type will get to that screen and know to turn back and choose the correct Issue Type ! Hope that helps some other people ! Have a great day,
[
| ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Improvement
Resolved
Critical
Allow Issue Types to be configurable to specific Projects
