Edgewall Software

Changes between Initial Version and Version 1 of TracDev/Proposals/BatchModification


Ignore:
Timestamp:
Jun 24, 2010, 7:17:17 PM (12 years ago)
Author:
CuriousCurmudgeon <meeker.brian@…>
Comment:

Legend:

Unmodified
Added
Removed
Modified
  • TracDev/Proposals/BatchModification

    v1 v1  
     1= Trac Batch Modification Proposal =
     2
     3''Proposal to add batch ticket modification functionality to Trac. See #525 for the original ticket.''
     4
     5== The Context ==
     6Currently 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.
     7
     8== Requirements ==
     9=== UI ===
     10The 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.
     11
     12=== Notifications ===
     13The 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.
     14
     15A 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.
     16
     17=== Timeline ===
     18Should each batch modification add one entry to the timeline, or a separate entry for each ticket that was modified?
     19
     20=== Permissions ===
     21The 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.
     22
     23=== Workflows ===
     24The 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.