|
History
| Log In
|
|
|
|
Yes, I believe the preferred option would be to present the user with the normal move issue screens.
Ben,
Post-functions cannot present the user with a screen, they simply perform some processing on a given input. This is why this functionality is not straight forward. Anton If possible, the post function move configuration could be pre-defined.
eg, the from project is known, and the to project is known. so the workflow schemes, issue types and other information undergo a known transition. This could be defined as part of the post function, then implemented automatically. Much like if I add the "Attachment" field to a screen and buttons and other things are added, it would be nice to have the same functionality with this operation. Actually, clone, move, link all wrapped up into one would be ideal for tech support / help desk situation for moving issues that turn out to be bugs from the support project to a programming project.
Moving issues into another project can be a fairly involved process, as JIRA offers a lot of flexibility in the way the projects are set up. Due to this flexibility the projects could be quite different to each other, and the information that needs to be provided in the Move Issue wizard heavily depends on how the source and destination projects are setup.
As the post function is executed after the issue has been transitioned through workflow, it is not possible to execute a wizard when the post-function executes. Therefore it is not possible to get the required input from the user to automatically move the issue. Having the required input saved as parameters to the post-function would be extremely fragile. If the configuration of the source or destination projects is updated, the input could be no longer valid. For example, if a custom field is added to the destination project and is made required, the input that is needed for the Move operation to complete will change. Therefore, it is not a good idea to implement Move Issue as a workflow post function. Due to these reasons I will resolve this issue as "Won't Fix". If the issues need to be moved once they reach a certain workflow function, the best way to do that is to use the Move Issue operation. To ensure this happens, it is possible to define a Filter that finds the issues in the given status, and subscribe to this filter: Then, go through the issues that have been found by the filter and move them. If the functionality that you are after is Clone then Move issue in a single wizard, please vote for JRA-1558. The solution for JRA-1558 will most likely involve implementing a new issue operation rather than a workflow post function. For more information on the way new feature and improvement requests are scheduled please see: Cheers, I am really confused, as I don't see this as a post function at all for all the reasons you just came up with. I think you are missing the way that I would implement this solution.
I would present this all to the user through a transition screen. So when you see the transition screen you would see: ======================================================== Project | Combo Box | v | Component | Combo Box | v | Priority | Combo Box | v | Status | Combo Box | v | Comment: | Display Large text box | _________
--------------- ============================================== The problem I see it is the OK button. How do you get the OK button to do what I want? In addition, I get the impression that people are having success using the Clone Move plugin. I would feel more comfortable basing a critical step of our work flow on something support by Atlassian. Please consider reopening this issue. Tom,
Being able to do a Clone and Move as part of the workflow transition would also be quite complicated, as a transition can display only one screen. The Move operation needs to be a wizard as the fields that the user needs to update depend on the chosen destination project. If this functionality was added, we would need to come up with some way of nominating that a transition in a custom workflow has to perform a Clone & Move, and therefore needs to become a wizard. We would prefer not to increase the complexity of a workflow transitions. This functionality would also become very problematic if users tried to execute the workflow transition as a Bulk Operation. Therefore, i believe the best way to implement the Clone & Move functionality is as a non-workflow issue operation, which is requested by JRA-1558. Once JRA-1558 is implemented, it may be possible to look at configuring a workflow transition at automatically redirecting the user to the start of the Clone & Move issue operation. Thanks, Difficult or not, you need to find a way to make it happen. I realize this won't be an easy thing, but if you look at how many votes this has already gotten and you only left it open for a couple of days, and then the votes for JRA-1558, it is clear that some sort of a solution needs to be provided. Should this be linked to JRA-1558? I would like to see you reopen the issue to see how important this is to the user base. Editing live work flows is a big task, yet it is being tackled. I would hope this would also merit the same effort eventually, in the next 12 months possible.
Tom,
I think we need to balance what is important to users with what can be realistically implemented and fits into a product, especially when taking into account other currently open feature requests (which have hundreds of votes). JRA-1558 is a solution which is much more likely to be delivered, and I am hoping that it will also cater for most use cases. If JRA-1558 is implemented, will it work for you? Especially if the issue operation is kicked off after he transition? You are right. I will link this issue to JRA-1558. Cheers, That and JRA-4821 get me most of the way there.
Why does this need to be two pages? If you add an attachment field to the work flow, the attach button automatically shows up? This seems similar if not the same as I am asking for. Yes the Clone and Move is not available as a base procedure yet, but once it is, why can't you add it to a work flow screen? The above would assume a deep Clone of data as described in JRA-4821. These options might be set as properties as this will probably not change. This will probably be set by an admin person and be used the same way all the time. Linking would also be appropriate. Hi Tom,
Thanks for the update. I am glad that JRA-1558 and JRA-4821 would help. To answer your questions: The problem is not so much the Clone operation, but the Move operation. The Move operation heavily depends on the current state of the issue, the setup of the current project and the destination project. Allowing users to update various fields of the issue on the Workflow Screen, then figure out what input we need and gather it using an AJAX style wizard would be quite error prone. Given the current workload and the number of other extremely popular issues that are currently open I do not think we will be able to address this. The problem with the Move and Clone operations during a workflow transition is also getting it to work as part of Bulk Workflow transitions. When working with lots of issues, the complexity here would be even higher. Cheers, |
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
 |
|
New Feature
Resolved
Major
Add JIRA move issue workflow post-function
The best we can do in this situation is to try to go with defaults for fields, and if they do not work throw an error. I am not too sure what to do with the status, as there is no real 'default' for this. I guess if the status needs to change we can throw an error.
The other approach coul be to ask the user for the destination project and issue type and then try to ask all the configuration information that might be needed. As we do not know the source project and issue type this is very difficult. Also, as things change keeping the configuration of this post function up to date is also very difficult.