Modify

Opened 14 years ago

Closed 10 years ago

#7709 closed enhancement (wontfix)

Batch modification should respect custom workflows

Reported by: sue.sml2006@… Owned by: CuriousCurmudgeon
Priority: normal Component: BatchModifyPlugin
Severity: normal Keywords:
Cc: Trac Release: 0.11

Description

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

Attachments (2)

MISTIC_workflow.bmp (57.2 KB) - added by dale.miller@… 14 years ago.
workflow with in_review and testing added - resolution settings
MISTIC_workflow.txt (1.5 KB) - added by dale.miller@… 14 years ago.
ticket-workflow taken from trac.ini file

Download all attachments as: .zip

Change History (9)

Changed 14 years ago by dale.miller@…

Attachment: MISTIC_workflow.bmp added

workflow with in_review and testing added - resolution settings

comment:1 Changed 14 years ago by 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.

comment:2 Changed 14 years ago by CuriousCurmudgeon

Status: newassigned
Summary: When updating status using batchmodify, use the workflow operationsBatch modification should respect custom workflows

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.

Changed 14 years ago by dale.miller@…

Attachment: MISTIC_workflow.txt added

ticket-workflow taken from trac.ini file

comment:3 Changed 14 years ago by CuriousCurmudgeon

(In [9392]) refs #7709

  • Created a separate branch for adding workflow support.

comment:4 Changed 14 years ago by 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.

comment:5 Changed 14 years ago by 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.

comment:6 Changed 14 years ago by 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.

comment:7 Changed 10 years ago by Ryan J Ollos

Resolution: wontfix
Status: assignedclosed

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.

Modify Ticket

Change Properties
Set your email in Preferences
Action
as closed The owner will remain CuriousCurmudgeon.
The resolution will be deleted. Next status will be 'reopened'.

Add Comment


E-mail address and name can be saved in the Preferences.

 
Note: See TracTickets for help on using tickets.