support.atlassian.com has the same problem in that I cannot ask my colleague at work to look at my support issue without giving him my login. And Atlassian is cheating around some of the missing functionality by having (at least) 3 different instances running on 3 servers. So they can configure each differently.

For example you a user wants to be added to an Active Directory Group. We have a list of groups and their owners, so we'd need a way of selecting from a list of groups and the ticket (or sub task) to be assigned to the owner. They would then hit Approve of Reject.

This simple example would solve a great many help desk issues for us.

Also, we would like parallel approvals. In other words an approval needs to be sought from more than one person before the next step. I believe this is forking and merging.

Anyway, this is a start. I'll add more after i've met with our helpdesk.

I would like to thank everyone for their input. We are taking your comments on board.

I am hoping to reply with something more useful some time next week after we have a chance to discuss internally.

Cheers,
Anton

http://jira.atlassian.com/browse/JRA-1549#action_65655

Cheers,
Scott

I'm also an enterprise user and support this petition. Our company is waiting very wishfully for assignee restrictions in workflows (JRA-6381). We are having a lot of trouble with workflow assignments to the wrong people.

Cheers,
Thorsten

I'm struggling to understand how features / improvements get prioritised. The customer voting system seems to count for nothing. This is the second most requested feature (188 votes) and yet the feature with the most votes (30) in release 3.7 ranks only about 50-th in the list.

Also, as a "Enterprise" badged application more development needs to been done to support Enterprise authorisation / authentication mechanisms eg ldaps and kerberos single sign-on.

Cheers ......... Geoff

The particularly important areas as:

• separate the primary keys on the users and groups tables from the login name, so that users and groups can be renamed.
• project-level admins.
• hierarchical user manager (basically users associated with a project, not the whole system)
• build a decent UI for the whole thing.

The main non-user-system requirements I need are:

• hierarchical components ("sub components")
• editing comments

As far as how the prioritisation goes, I would hazard a guess that it's along the lines of a former employer I had (in the software game):

• Build shiny new bells and whistles that will attract new sales. Because new sales means more money.
• Sideline issues from existing clients because we've already got their money (and not thinking that established clients are a lot easier to get MORE money out of, than making new clients).

Note: the above policy is that of my former employer. I'm not saying Atlassian are THAT cynical, but I suspect that "new clients" vs "existing clients" is a major consideration in how they plan their releases. I agree with the basics of that policy, but I think the balance here is a bit out of whack.

You said:

along the lines of a former employer I had (in the software game): Build shiny new bells and whistles that will attract new sales. Because new sales means more money. Sideline issues from existing clients because we've already got their money (and not thinking that established clients are a lot easier to get MORE money out of, than making new clients).

I think we must have worked for the same person ...
and being in Quality Assurance, my goals always conflicted with his. Having said that, I don't think that's really Atlassian's philosophy. They have certainly implemented many enhancements, including many of my requests, since I went live with 3.03, including screens in 3.2 and many improvements in 3.6. Still, some of the high profile issues like those linked here are IMHO far more important than WIKI rendered comments and project roles, major enhancements in recent/upcoming releases.

I do understand that even with the growth Atlassian has seen there are limited resources. What I don't understand is how users like us are able to create the missing functionality (e.g. JRA-1100) while Atlassian can't find the time or resources to do it. Anyway, I'm glad I chose JIRA (twice ), and I look forward to the product maturing even more.

That said, there are items that would help me, or that my users have been asking that are on this list. And while I may not agree with the decisions, I know I'm not the only administrator that they need to code features for, I'm going to trust whoever they have as a Product Manager to strike the balence between new users (and new money) and current users (and recurring license money). I'd rather have this a tool that grows and matures then one that fails because it was listening only to a subset of its install base.

I would like to thank everyone for their comments and input. We can see that this issue is a good "hub" for recording the features you believe are important for enterprise deployments.

This issue, however, does not help us prioritise between features that you believe are important. Due to the number of issues mentioned here,and the complexity of some of them, we will not be able to implement them all at once. Quite a few JIRA customers are voting for this issue, and while the popularity of the whole list goes up, it does not help us organise the issues in order of importance.

Due to this reason, we would like to resolve this issue, and ask you to vote for the actual individual features that are important to you. This will greatly help us to prioritise them.

Thank you for your help and understanding.

Good idea.

I have created:
http://confluence.atlassian.com/display/JIRACOM/JIRA+4.0+Enterprise+Requirements

Thanks,
Anton

For tracking purposes i even find the jira list better. The votes are still done in jira, and in confluence there isnt any added content, is it?

it's just for my understanding