|
Can you please fix this asap. We are using one workflow for a growing number auf projects. Changing transition screens, adding post functions, adding transitions forces me deassign and reassign the workflow for all
 projects. As Thomas mentions moving projects back and forth between copies of workflows to make a workflow change is not too flexible, but it is even more annoying that this is logged in the issues (at least in version 3.3). This means that searching on issues by modification date becomes useless because the modification dates of the issues are set to the date on which the administrator changed something to the workflow! In other words: small changes to a workflow pollute the database unnecessary.
I've logged a vote but can I just add my support for this issue being resolved asap. Our current review of Jira (vs TeamTrack) has been going well up until this sticking point. At the moment the inability to edit activated workflows is being used as a reason not to adopt Jira at all. If we could at least have an ETA for the fix that would downgrade the importance of this issue.
Matt. Hi Matt,
Thank you for your comments on this issue - as Nick has mentioned, this is an issue we are looking to address in a future release, but this issue has not been scheduled as yet. The following document details how new features and improvements are scheduled: http://confluence.atlassian.com/display/DEV/Implementation+of+New+Features+and+Improvements Regards, Hi:
I had headache changing a workflow by copy the work flow schema, delete the assignment of every issue type, copy the workflow, assign the workflow to every issue type, and finally do this changes:
bye Alvaro Alonso We are hoping to improve this in JIRA 3.6
When is version 3.6 expected?
thanks, "Anton Mazkovoi (JIRA)" <jira@atlassian.com> To Subject [ http://jira.atlassian.com/browse/JRA-7661?page=all Anton Mazkovoi updated Fix Version: 3.6 We are hoping to improve this in JIRA 3.6 transition? – ********************************************************************************** *************** Paul,
We started working on JIRA 3.6 today. Without making any hard promises we are hoping to release in 3-4 months. Anton A rough way of getting around the workflow limitations until they are (hopefully) solved in 3.6 is:
This has worked for me without any problems. Of course - think about what you are doing. Most modifications will give you no problems, but deleting transitions could, make sure you don't delete the only possible transitions for some of your issues. Hmm... bad way of explaining, i'll try a better one.
Nice fake-out Lars. When I started QA'ing web applications I read an article on how in the early days of e-commerce, people figured out that they could alter the price of a product because it was included in the URL. So they just modified the URL and got a lower price. In fact, in one case they ordered -3 items by over-riding the QTY, which was also passed in the URL. The billing dept didn't notice the negative amount because it was all computerized. So the credit card got a nice CREDIT instead of debit. And the shipper figured it was a mistake in the paperwork so they shipped them all 3 items too. I always test my web applications to see how much damage I can cause to get around security by doing nasty things like this. Of course, I never try to break JIRA because it's my friend
 Please count in my vote. (yes, I added it to Voting)
Lars,
Excellent job on the...oh...what's the word for that..."workaround" maybe? Ted I was able to add the transition step in the active workflow using the "workaround". If I need to make a change to the step, then how can I accomplish that? Let say I add step "send to QB" but then it really should say "send to QA", how do I change that on an active workflow? Or if I added the step in error to an active step, how can I delete that step?
Same way. Just go to the relevant page using your duplicate (inactive)
workflow, and copy the URL of the link that would perform the action you want to perform, then paste the URL into your favorite browser and change the workflow name. You can do almost anything that way. Be careful about doing this, however. I personally won't use the workaround for adding or deleting transitions or steps. Too much chance of it messing up something someone is doing at the time, which could lead to data corruption. I only use it to change existing steps, transitions, etc... – Matt Kenigson +1 From Amplefuture Ltd. I had to create a temporary workflow scheme, park all projects there, change my flow and re-assign all projects.
Can someone at Atlassian advise when 3.7 is expected to release since we're planning on upgrading? If it's very soon, we would rather wait to do the upgrade to 3.7 instead of 3.6.5. Thanks
Irene,
Unfortunately this will not make it into 3.7, so I would advise upgrading to 3.6.5. Cheers, Scott,
Perhaps you can elaborate on when this will be available if it is not going to be 3.7 In the mean time our maintenance time exeeded. Nice way to enforce re-buying
 As a new customer, Atlassian's inability to address when this issue will be resolved is really lowering my opinion of the company. I am paying 50% maintenance costs for no answers. I suppose the 50% maintenance costs are nothing compared to the cost to our company of having to reassign workflows all the time.
I am also VERRRRY interesting by this new feature. JIRA is used in our compagny by around 3000 users. We have 160 projects. This tools is the most major tool today. for us .
Sometime I should change the workflow by the XML way, but I can not do all changes I need (rename step). Do you think we can have an hope to have this feature in JIRA, in the future major release ? Many thanks Carole, How many issues do you have with the # of projects and users you
have. We're expanding JIRA to a lot more users and adding more projects so we want to get an idea what the highest volume of issues it is at least capable of. Thanks Sorry Irene for the delay of my answer ...
We have 160 projects created on our JIRA project, we expect to have around 200 projects at the end of the year. We have 3000 users, but not connected in the same time ! In the same thime, I suppose they should be 400. We have 50 000 issues, around 5 000 issues per month. Carole As has been mentioned in another JIRA item, this will help a lot of us enterprise level users who have large numbers of projects. It's just not possible any longer to make workflow changes on existing projects, because of the huge level of work involved. I can easily see this tool being discarded in the future because of the inability to make simple changes to our processes.
I am also extremely interested in this being fixed. It is SO laborious to have to copy workflows and workflow schemes, make changes, migrate every project to the new one, then delete the old one. It's compounded by the fact that you can't even RENAME a workflow or workflow scheme, which makes no sense at all, given that it must be referred to everywhere by an ID. I can certainly understand the current behavior in the case that workflow steps are being changed/added/deleted. But, simply renaming something, changing transitions, etc. should be much easier to do than it is.
+1 which makes 113 votes now, when is this due?
I'm getting slightly annoyed at Atlassian over this.
Our maitenance has now run out and the last correspondence from Atlassian was on 15/Oct/06 06:59 AM Unacceptable in my opinion. Could someone from Atlassian please do us the courtesy of responding???? I would think people involved in this issue are entitled to a free upgrade to whatever version this is included in as well. James I have personally e-mailed Scott Farquhar - may as well go straight to the top.
Absolutely agree with this. We have a company policy to use the same workflow for all our customer projects. This means that every time we want to modify an existing workflow or even add a new workflow to an existing scheme, the procedure to update is nothing short of painful and extremely time consuming. On top of that, every issue shows that the workflow was updated. We have issues created months ago where the Change History is 99% workflow updates. This is visible to our customers too which doesn't look good.
So a more flexible way would be great. And at the same time, please make it optional whether the workflow update is shown in the Change History Thanks Hi Guys,
Scott Farquhar got back to me about this and is looking into it for us. I will let you know if I hear anything. James James,
I am curious if you heard anything from Scott Farquhar, we recently received a renewal notice from Atlassian sales and I am wondering if we should continue paying for support. The problems associated with changing workflows is making it very difficult to continue working with Jira. Dan No, he assured me he'd look it, that's as far as it got.
Bit disappointing. We have not renewed our support because of stuff like this. All we want is some visibility on how they are addressing this - i.e. a rough date would be nice. James Yes, extremely disappointing.
I know this issue should not really be used to voice these kind of concerns but when Atlassian does not even care to update us on the situation, I see little other choice. In a few months time, I will have the task of convincing our management whether to re-new the licence for another year and it's not looking too good. Guys, if you are busy discussing it internally which we hope you are, please provide an update asap. Thank you For the time being I'm using the workaround suggested here
 if I do not need to remove or add some state in my workflows. Until now it worked without problems... This came from Anton Mazkovoi.
Dan ------ > We are in the process of evaluating whether to renew our support Thank you for your feedback. We really appreciate you taking the time to At the moment we are working through the list of popular feature For example, the latest major release (JIRA 3.9) resolved 494 votes: In JIRA 3.10 we are working on addressing over 350 votes. Some of the Editable worklows is quite high on the list, and I am hoping that we May I ask, however, why I would be very interested in hearing your use case, as it would help us I will also forward your e-mail to Tony Dagger, the Director of Support Cheers, Why is it important to us:
1. Yes, we edit our workflows often. As a software development group, we are often tweaking our process to try to become more efficient. However, this means that we often want to add/remove transitions. 2. The changes we most often want to make are adding & removing transitions. Changing steps, allowing short cuts, etc. What we've been doing is copying a workflow, changing the new workflow ("workflow version 3.175" or something silly), then painfully migrating each existing project over to the new workflow (20-30 projects). If a project is mostly done, we'll just leave it in the old workflow to save time. It's a huge pain, and a large negative about the system. We have the same needs of editing workflow as David described above (50 projects).
I would just add to this that I was delighted to see the role management implemented in JIRA 3.7 (I think it was released in this version). Some of our transitions have conditions based on Groups, and because the current process to change a workflow is too long, we are still not using the role feature, which is really a shame since it is a brilliant new feature which answers some of our needs. Let me do just a remark. When we have started to work with JIRA (version 3.3), there were mainly compliments and satisfaction comments done around your tool. From a few months now, this problem of editing workflows seems to be really really annoying for some of your customers (like me). It's hard to believe that this problem is not one of your priority, but you maybe have other things to work on more important than this one. We have version 3.9 (Enterprise) and this workflow editing problem does not appear to have been fixed in this version.
I have had major problems with this....it's been painful..lots of tears! F.T.A.O. JIRA - Can you please log an update against this issue? Hi Guys,
Thank you for your input. Choosing what features to implement each release is the hardest part of our jobs. The thing that makes it most difficult is that there are a lot of very important things to do, and we only have limited resources to throw at them. I believe this will always be the case, but we will continue to do the best we can. Unfortunately, at the moment I do not have an impementation date for this, but please be assured that this issue has our attention. I apologise for not being able to be more specific. Cheers, I missed the previous question about why we need this. I find most often that I'm tweaking our workflow like adding a new transition etc, but often simple things like adding a condition or post function etc. It's rare we introduce entire new states, but it does happen on occasion.
How many votes do we need to scrounge up until this becomes the most important issue? Anton and the Jira team,
This really sounds like a complex feature to be developed and of course having the lack of resources you might just never find the time in the nearest future to implement it. What will work for my case is being able to edit the workflows without the need of deattaching them from projects. Thanks Hi Alexey,
I understand how frustrating it is to have to move all your issues to a new workflow, just to make a little tweek to your current workflow. If we could quickly implement a project lock/unlock solution we would. You are correct in thinking this is what we need in order to provide you with the functionality you are after. Unfortunately this is not as easy as it may sound. At the moment in JIRA there are may subtle ways that projects, and the issues within, are modified. Locking down an entire project and all its issues will take a significant amount of development time. I appreciate your interest in the problem but unfortunately we do not have an implementation date for this at the moment. Thanks, Hello Anton and Atlassian Devopment,
While I understand and sympathize with your position, I'm surprised with the continual push-off of this improvement especially given that it's in the top15 list. I think the fustration the most of us feel is that workflows often need to be tweaked after they have been established, sometimes days after the project was created other times months. In our case, we have conststant workflows across or development division which consists of 30 projects some of which have 30,000 issues each. I did the calculations and moving projects off and back on that workflow would be a whole day of downtime for us to change something as simple as a new condition on a transition based on business needs. Do the cost analysis on that and you're over a million in lost productivity. As for the implimentation of this, if we can already modify the workflow behind the scenes and restart jira to make it take, why can't we do the same in the UI? Create a shadow copy as the admin edits it and apply those changes on the next restart. I also realize we wouldn't be able to remove states or possibly rename them, which I can live with. Yes, it would be the inconvenience of a 5 min restart, but it's still better than trying to hack up the XML or doing all the moves. The bottom line is this, we choose features based on need, but also on overall impact to our biggest customers. Most of the people commenting here are your biggest customers, as the small ones don't seem to have as many issues with this. Our company just purchased Confluence and potentially Crowd and are considering splitting our Jira instance since we're over 93,000 issues and growing at about 10,000 a month with more project imports in the wings... meaning we're definately a larger customer. This may be a deal breaker for expanding further with Atlassian if it isn't resolved. If you're going to apologize with a comment again, then support your general guidlines, don't bother I've heard it. Instead, let me know when someone is going to at least come up with an acceptable work-around. We whole-heartedly support this feature request and strongly agree with Dan's last comment
and the one from Stephane Durand regarding moving to project roles. We have 78,000 total issues in 80 projects. Our biggest project has 30,000 and many have a few thousand each. A recent workflow change took 34 minutes for 4,300 issues. As a reference point, we have HP ProLiant DL580 , 4 dual core processors , 8 GB of RAM (3.5 devoted to JIRA), running on MS SQLServer 2005.
The kinds of changes that we do on a regular basis are:
We also prefer to have the option to now show workflow changes in the change history. Having said all that, I am familiar with Atlassian's long list of most popular JIRA feature requests Please just keep in mind that as time goes by, large customer installations like Dan's and ours are growing even larger and more tedious to maintain. And these problems are becoming compounded. Of course, don't let it go unnoticed that you make an awesome product! We are big JIRA fans and would be very reluctant to part with it, hence we put pressure on you to make it even better just to add - this isn't something only large customers want. we're a small open source project and only make limited use of the workflows feature, but even creating and editing simple custom workflows is a lot more effort than it could be.
Is this also going to address I don't see it included in the references, but as I just stumbled across it the other day, I though it would be best to ask incase it was overlooked. Hi Jeff,
Thanks for pointing this out. I think we'll be able to include a fix for Cheers, This feature has now been implemented and will ship with JIRA 4.0. It is now possible to create a draft workflow for any active workflow, that can be published without requiring a full workflow migration (in other words instantaneously). The only limitations when editing a draft workflow are:
We also implemented Cheers, And the release date (rough one, please)
YeSSSSSS! .. hopefully 4.0 will be released tomorrow
|
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
 |
|
Improvement
Resolved
Major
Ability to Edit Active Workflow - Editing Workflows is too inflexible
destinataire(s) précité(s) et ne peut être autrement distribuée, copiée ou utilisée. Le contenu de cette communication peut être assujetti au privilège du secret professionnel. Tout droit à ce privilège est expressément revendiqué et nullement abandonné. Si vous avez reçu cette communication par erreur, veuillez nous en avertir immédiatement en répondant à ce courriel ou en nous appelant. Veuillez également effacer cette communication (et tout fichier rattaché) sans en conserver une copie. Merci.
. Thanks for listening.
Thanks for your comments on the issue. We are aware of the limitations of the workflow editor and look to improve it in future releases. The good news is that our framework can handle "live" updates we just have to update our editor we use to manipulate it. It is quite a complex piece of work making sure that all changes are valid.
We will try and keep you updated on this issue.
Cheers,
Nick