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'. 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. 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. reset all open tickets to "low" priority and "unscheduled" for example).
(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. The biggest reason seems to be auditing requirements. (CuriousCurmudgeon) That was my initial thought too, but experience has shown me that many teams want these permissions to be separate. 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. (osimons) I do not like the separate permission, and to me it makes no sense. 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. The plugin adds a separate permission for batch modification. Here as well we could have one summarizing event. Should each batch modification add one entry to the timeline, or a separate entry for each ticket that was modified? A mail summarizing the changes should be enough. We definitely should try to not send 100s mails to the same user. That would be a first step.Ī 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. This could be done the "normal" way via the ITicketChangeListener once #7758 is done (or the planned new IResourceChangeListener ( #8834) and the Announcer support). The current plugin does not integrate with email notifications. Time for an integration branch, don't you think? See below. This has been implemented in the 0.7.0 release of the plugin. 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. The current plugin UI does not fit at all with Trac. You can check out progress at Requirements UI
Moving this into Trac has been a commonly requested feature for years. This is only supported through the use of the BatchModifyPlugin found at . The ContextĬurrently Trac does not support modifying a batch of tickets at once. See #525 for more details about the integration process. DONE This proposal has been integrated for the 1.0 release.
0 kommentar(er)
