|
|
|
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
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 | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
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