Edgewall Software

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

Jul 28, 2010, 5:45:35 PM (12 years ago)
Christian Boos

Integration in Trac welcomed ;-)


  • TracDev/Proposals/BatchModification

    v5 v6  
    1212 This has been implemented in the 0.7.0 release of the plugin.
     13  (cboos) This looks good to me. Time for an integration branch, don't you think? See below.
    1316=== Notifications ===
    1417The 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.
    1619A 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.
    18  We definitely should try to send 100s mails to the same user. A mail summarizing the changes should be enough. (cboos)
     21 We definitely should try to **not** send 100s mails to the same user. A mail summarizing the changes should be enough. (cboos)
    2023=== Timeline ===
    2831=== Workflows ===
    2932The 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.
     33  Seems to be addressed now (`_check_for_resolution` / `_remove_resolution_if_not_closed`)
     36== Integration in Trac
     38While 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).
     40Further 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).
     42A few ideas:
     43  - 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
     44  - seems there are lots of duplication in batchmod.js (from query.js);
     45  - the `ITemplateProvider`, `IRequestFilter`, `ITemplateStreamFilter` methods will no longer be needed
     46  - 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)
     47  - 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`)
     48   - there should be **one** transaction for all the ticket modifications, not one per ticket change!
     49  - 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
     50   - same thing for the conditional inclusion of the `batchmod.html` template from the `query.html` one