Brian Meeker wrote: > The only feature I removed was the ability to not modify the > changetime of each ticket that is modified. Some users use the plugin > in such a way that modifying changetimes messed up there internal > auditing. I don't think this is the sort of feature that belongs in > the Trac core though.
Agreed. > * Currently I have separate files for batch JavaScript and CSS. These > are only included on the query page if the batch module is enabled and > the user has the TRAC_BATCH_MODIFY permission. Should these be > integrated into query.js and report.css? Yes, they should. Merging the .css files has probably no impact at all. As for the .js... > This would eliminate some > duplication, but with the side effect that unneeded styles and scripts > could be included on the page. Another option would be to refactor > query.js so the common functions are not in the ready event. I would try to measure the performance impact of leaving it on all the time, and if it's small enough (or not measurable), leave it there. I suspect this will be the case. > * Are there any guidelines for adding new config options? Currently > the plugin has three config options related to the handling of text > fields. There a couple of new fields I have considered adding as well, > one for excluding certain fields from batch modification and one for > adding certain fields by default. Other than keeping the number of options as small as possible, I don't think so. Note that I haven't had a chance to look at the code yet, so this is just general advice. Thanks for working on this! -- Remy
signature.asc
Description: OpenPGP digital signature
