Changes between Version 5 and Version 6 of TracDev/Proposals/BatchModification

Timestamp:

Jul 28, 2010, 5:45:35 PM (14 years ago)

Author:

Christian Boos

Comment:

Integration in Trac welcomed ;-)

TracDev/Proposals/BatchModification

@@ -11 +11 @@
 
  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.
@@ -16 +19 @@
 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 send 100s mails to the same user. A mail summarizing the changes should be enough. (cboos)
+ We definitely should try to **not** send 100s mails to the same user. A mail summarizing the changes should be enough. (cboos)
 
 === Timeline ===
@@ -28 +31 @@
 === 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 [SubversionRepository#Mirrors 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" [TracDev/CodingStyle 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