Batch modification should respect custom workflows

[sue.sml2006@…]

when moving a ticket from release in progress to test in progress status, we assign the ticket back to the reporter using set_owner_to_reporter operation. if batchmodify is used to execute this state transition then this owner change does not happen. It would be nice if the batchmodify command used all the operations as specified in the workflow

[dale.miller@…]

workflow with in_review and testing added - resolution settings

[dale.miller@…]

With all the special handling in possible workflows this could be very complex.

In our workflow (see attachment) we set the resolution when a ticket goes from accepted to in_review or new to closed.

In ticket 7303 these changes were made to BatchModifyPlugin.

• Setting a resolution automatically sets the status to closed.
• Setting the status to something other than 'closed' will remove the resolution if there is one.

If we want to change a resolution our workflow requires us to move a ticket to "reopened". In our case I would like to see a checkbox on the resolution and status fields that could be selected to not do the automatic changing of the status and resolution.

[CuriousCurmudgeon]

You are correct, this is could be really complex and that is why it hasn't been addressed. I need to dig into custom workflows to determine the best way to hook into them.

Any opinions on what should happen if a subset of your selected tickets cannot be modified due to it violating the workflow? I lean towards all changes being rolled back and listing out the tickets that were invalid to the user. This is also the easiest to implement since all changes already occur in the same transaction.

With regards to more checkboxes, I am against this. I would rather address the issue properly then clutter up the UI with more checkboxes. I knew adding that feature in #7303 could cause problems for custom workflows, but felt that the benefits outweighed the gain.

Finally, anybody reading this ticket, if you have a custom workflow, please attach it, preferably directly from your trac.ini file. The more samples I have of what people are actually using the better I can test whatever is implemented.

[dale.miller@…]

ticket-workflow taken from trac.ini file

[CuriousCurmudgeon]

(In [9392]) refs #7709

• Created a separate branch for adding workflow support.

[CuriousCurmudgeon]

See ​this thread for more information on how this could be implemented.

The big problem is that the plugin will need modified to apply actions to a group of tickets instead of directly changing the status. Right now I am planning to split batch modification into two parts. First, users will choose the tickets they want to modify as they do now. Then they will click a batch modify button that will take them to a second screen. This UI will be similar to modifying a ticket, with the valid actions being the intersection of the valid actions for each selected ticket. Submitting this second form will actually modify the tickets.

[CuriousCurmudgeon]

(In [9399]) refs #7709

• Created a new template to insert into the query page. Users will now just select the tickets they want to modify and click a button. This will take them to a page where they can actually choose what to modify.

[CuriousCurmudgeon]

(In [9400]) refs #7709

• Renamed web_ui.py to query_batchmod.py. This will become the query page integration. Everything else will be moved to a new module.

[Ryan J Ollos]

The plugin is deprecated since it has been integrated to the Trac core for 1.0. Upgrade to Trac 1.0 and uninstall this plugin to get the latest functionality. Enhancement requests can be directed to Trac.