Trac Batch Modification Proposal

DONE This proposal has been integrated for the 1.0 release. See #525 for more details about the integration process.

The Context

Currently Trac does not support modifying a batch of tickets at once. This is only supported through the use of the BatchModifyPlugin found at ​http://trac-hacks.org/wiki/BatchModifyPlugin. Moving this into Trac has been a commonly requested feature for years.

Code

You can check out progress at ​http://github.com/CuriousCurmudgeon/trac-batch-modify

Requirements

UI

The current plugin UI does not fit at all with Trac. What about something similar to the custom query filter UI? Users would select the items they want to modify on each ticket, similar to how filters are added now.

This has been implemented in the 0.7.0 release of the plugin.

(cboos) This looks good to me. Time for an integration branch, don't you think? See below.

Notifications

The current plugin does not integrate with email notifications. This could be done the "normal" way via the ITicketChangeListener once #7758 is done (or the planned new IResourceChangeListener (#8834) and the Announcer support). That would be a first step.

A specific interface (or extra method to the IResourceChangeListener interface) may be more appropriate though, like it would be for other cases of batch modifications, such as #4582 and #5658, or the batch WikiRename feature, see ticket:4412#comment:8.

We definitely should try to not send 100s mails to the same user. A mail summarizing the changes should be enough. (cboos)

Timeline

Should each batch modification add one entry to the timeline, or a separate entry for each ticket that was modified?

Here as well we could have one summarizing event. See also #9205. (cboos)

Permissions

The plugin adds a separate permission for batch modification. This seems to be preferred by users of the plugin who do not want every ticket editor to necessarily be able to batch modify them.

(osimons) I do not like the separate permission, and to me it makes no sense. If you are allowed to change each ticket, then surely you should be allowed to modify them through a batch update? If the feature is to become an integrated part of Trac, then the TRAC_BATCH_MODIFY permission just adds complexity and administrative overhead.

(CuriousCurmudgeon) That was my initial thought too, but experience has shown me that many teams want these permissions to be separate. The biggest reason seems to be auditing requirements.

(cboos) Another way to look at it is about the amount of "harm" that can be done to a project, intentionally or simply by misguided people: if someone with a simple TICKET_MODIFY could use the batch modify facility, he could in two or three requests put the entire project in a pretty unusable state (e.g. reset all open tickets to "low" priority and "unscheduled" for example). As we don't have yet a "batch undo" facility (that would be hard I suppose), the only way to prevent this is to reserve this feature to trusted people, like we do for TICKET_ADMIN. So I think it's only in the case when a project needs to differentiate between "full" TICKET_ADMIN and people able to modify batches of tickets that the new permission would be useful, otherwise in most cases TICKET_ADMIN should be enough.

Workflows

The plugin as currently written allows for tickets to be put into an inconsistent state, such as with a resolution of 'closed', but with a status of 'accepted'. This needs to be addressed.

Seems to be addressed now (_check_for_resolution / _remove_resolution_if_not_closed)

Integration in Trac

While not all of the above requirements are yet dealt with in the plugin, the user interface from version 0.7 looks good enough to me to be a worthwhile addition to the core (cboos).

Further improvements can be done later on that basis. I'd like to see a 0.13 branch of Trac (use our git or hg mirrors), with the batchmod plugin integrated in the trac/ticket subsystem (perhaps directly inside query.py).

A few ideas:

• looks like there are tabs in the .css and .html files; other "usual" coding style cleanups are needed in the .py code as well
• seems there are lots of duplication in batchmod.js (from query.js);
• the ITemplateProvider, IRequestFilter, ITemplateStreamFilter methods will no longer be needed
• I don't see a real need for a separate BatchModifier class, this can be merged in the BatchModifyModule (it's still interesting to keep that individual module, though, so one can choose to disable it completely)
• For the form processing, why not target a new URL (e.g. "/batchmodify"), so that you could have the BatchModifyModule be a real IRequestHandler (merge the current BatchModifyModule.pre_process_request and BatchModifier.process_request into a new BatchModifyModule.process_request)
  • there should be one transaction for all the ticket modifications, not one per ticket change!
• For preparing the form data (the bits currently in BatchModifyModule._generate_form), this could be done in the QueryModule if the BatchModifyModule component is enabled
  • same thing for the conditional inclusion of the batchmod.html template from the query.html one