Batch Modification Functionality

[anonymous]

The following is a request for enhancement.

I recommend that Trac implement batch modification functionality. This would allow users to modify several fields of several tickets that match a certain criteria in a single process.

Bugzilla 2.17.7 currently implements such functionality in the following way (see ​http://landfill.bugzilla.org/bugzilla-tip/):

• first, the user performs a query
• on the resulting bug list page, there is a link at the bottom of the page: "Change several bugs at once"
• on following that link, the same bug list reappears with a checkbox in front of each bug (this allows the user to hand pick a subset of the bugs to modify). This page also contains all the fields in a bug at the bottom of the page. Each of the fields contains a, "--do_not_change--" value by default.
• the user selects the bugs to batch modify
• the user modifies the fields needed to be changed in the fields at the bottom of the page
• the user clicks "commit"

Why would such functionality be useful? Here are some example scenarios:

• There's a milestone titled "Next Mainstream Loadbuild". Thus, when a designer closes an issue in the main stream / trunk, they don't need to know the number of the next loadbuild, they simply use the "Next Mainstream Loadbuild". Then, upon the next successful loadbuild, the loadbuild guy can do a batch modification, changing all issues that are closed and have a milestone of "Next Mainstream Loadbuild" to the actual build number. VERY USEFUL. The designers don't need to be intimate with every single possible build number / milestone.
• Another scenario: management has decided that all unresolved issues that were targeted to be addressed in load x are now to be targeted for load y. A batch modification would make this job a single task, as opposed to n tasks.

[daniel]

Thanks for the references, and presenting the idea. Seems cool.

[brianhv]

I think a more convenient UI would be to have a drop-down in every row for columns that the user wants to affect. For example, a priority-editing query would have drop-downs in the priority column for each row. That way, one ticket's priority could be lowered at the same time another's is raised.

[cmlenz]

In my opinion, batch updates of tickets would be a good fit for the query module. How exactly the functionality is made available in the UI is up for discussion. I personally like the "edit each row via <select> or <input type=text>" better than the bugzilla approach.

[cboos]

#2623 has been closed as a duplicate of this one.

[anonymous]

Let's get on this one guys. This one is a big deal.

[cmlenz]

#3388 has been marked as duplicate of this ticket.

[cboos]

Screenshot added on behalf of Steven Martins (illustrate how the Mantis user interface for this feature looks like)

[cboos]

Screenshot added on behalf of Steven Martins (illustrate how the Mantis user interface for this feature looks like)

[cboos]

#3426 was also marked as a duplicate for this one.
That ticket suggested to do it the "Mantis" way,
by having a checkbox next to each ticket in a list (custom query?),
enabling you to manipulate at once all the selected tickets.

See attachment:Mantis01.png​ and attachment:Mantis02.png​.

[Russell Hind <rhind@…>]

IIRC, Bugzilla does it this way too. When you edit multiple, you get a check box by each ticket in the list so you can select the ones to edit, and the standard properties at the bottom so if you change a property such as component or milestone, it applies to all selected tickets. (Can't provide screen shot as don't have a bugzilla installation up and running any more since moving to trac)

[Markus Tacker <m@…>]

I've made a mockup of a possible batch edit screen in trac. Unfortunately I cannot add attachements at the moment as I get an UnicodeDecodeError so you can see it here: ​http://m.tacker.org/blog/wp-content/uploads/2006/07/batchedit.png

[pkou at ua.fm]

It looks like I have expected to see/implement it! Thank you!

The only things that are missing:

• Comment field where it is possible to enter a common comment for several tickets;
• Action fields where it is possible to see the ticket actions that are common for the selected tickets.

[track+dasspunk at gmail dot com]

I desperately need this and like the mockup but I would also suggest adding a text box that would append it's contents to the bug.

[adam.creeger]

This looks great. May I also suggest that the "Batch edit tickets" box is collapsed initially, with the option to open it if necessary?

[anonymous]

Here is something I am working on...

​http://trac-hacks.org/wiki/BatchModifyPlugin

-Ashwin

[anonymous]

I'd like to offer a slight variation on this theme. I wrote a Quick Change module for a task tracking intranet (attached). I first thought about going down the road described above, but the more I used the system, the more I decided that what I wanted was field-by-field changes that may vary row-to-row. Meaning: I didn't want to force users to make the same change for every item checked. I might want to change 10 items to a new version, but change their priorities one-by-one within that version. So, I just allowed the user to select a number of items to quick change and then the next page (or the same page if you love Javascript) gives comboboxes and text fields allowing you to make the changes in a spreadsheet-like style. Much more powerful, useful and user-friendly.

To illustrate, have a look at the attached screenshot. I selected three items to quick change. The first 3 columns are editable on an individual basis. In the trac case, almost every column should be editable.

​ftp://ftp.ict.usc.edu/dbw/temp/Capture_3.jpg

Thoughts?

[conny@…]

I believe that there are two slightly different and separate usecases:

• Multi-item, multi-property edit (itc.usc.edu)
  • User checkboxes several tickets from a query-results list.
  • User follows a link to a separate view where all/multiple properties can be quickly for all the selected tickets.
  • User clicks submits them off all at once.
• Few batch-updatable properties (Mantis)
  • A new section in the trac configuration decides what properties should be available at the bottom of query result pages.
  • User checkboxes several tickets from a query-results list.
  • User selects new values for the property/-ies directly in a form on the page, and clicks Batch Update.

[anonymous]

Well said. I think both are useful. My issue with #2 is that batch modify touches every item in the result set. That's fantastic if you only want to change ALL the items in the set. My experience, however, is that more often than not, I want to modify multiple items, but rarely ALL of them. In those cases, it's really hard to get a SELECT statement to pick out exactly the ones you want. For example, maybe I have 30 tickets left for milestone 1.0, but I know there is now only time for 15 or less. So, I want to move half the tickets to milestone 1.5, and I want to modify the priorities of the 15 tickets that are left to make sure they get done in the proper order. I really can't use batch modify to do this, because I can't easily (a) select only 15 and (b) modify the particulars of the other 15. Changing 30 of them by hand is super painful. So, my suggestion would be to combine (a) and (b) into one piece of functionality.

Have the top row be GLOBAL CHANGE and then have pull-downs, etc. for that row just like you do for the individual rows, and then you have the row-by-row capability as outlined above. So, if you select the GLOBAL CHANGE milestone to 2.0, it will change that column for every row (solves your (a) case above), but if you leave milestone in the GLOBAL CHANGE row as <unchanged>, then you can change individual lines. That is the combination of (a) and (b) above.

If you really want this to work well, you add the checkboxes on the left side (as described earlier above) with a (select all) checkbox on the global change line. Now you have amazingly fluid functionality. You can do a global change that only affects n items in the selection set (rather than setting the dropdown for n lines). So, you get the best of both worlds.

Does that make sense? If not, I can mock something up.

[anonymous]

#4727 marked as duplicate.

[chad@…]

​FogBugz has a stellar implementation. The rows of a query results page (QRP?) all have checkboxes, and there is a "select all" knob. The cool thing, though, is that the QRP implements the shift- and ctrl-click semantics familiar from spreadsheeting and other apps. I.e., click anywhere on a row to select that row. Then shift-click on another row, and it selects the row range from the first-clicked to the second-clicked.

In FB, you then click an "Edit" button (they also give you keyboard shortcuts for all this), and you get a ticket mod screen that lists all of the tickets in scope instead of a single ticket description.

[henko@…]

A (more advanced?) alternative here is what ThoughtWorks?' Mingle does. There you have a grid view, where you can group stories (tickets) in "swimlanes" on any properly you like, for example milestone. You can then just drag a story from one such swimlane to another to change the value for that property. For example change from one milestone to another. It's insanely convenient. AJAX at its best.

Their ​release planning screencast does a very good job at describing it.

[sid]

#6257 was marked as duplicate of this ticket.

[eblot]

#6715 was marked as a duplicate of this ticket

[anonymous]

Lack of bulk-edit capabilities is the BANE of any project manager currently using trac. We don't need no stinkin' AJAX madness, the mock up shown here is perfect and follows the rest of the patterns in TRAC to a tee:

​http://m.tacker.org/blog/wp-content/uploads/2006/07/batchedit.png

This ticket is from 2004 and people clearly need it, who is going to step up?

[Markus Tacker <m@…>]

Replying to anonymous:

Lack of bulk-edit capabilities is the BANE of any project manager currently using trac. We don't need no stinkin' AJAX madness, the mock up shown here is perfect and follows the rest of the patterns in TRAC to a tee:

​http://m.tacker.org/blog/wp-content/uploads/2006/07/batchedit.png

This ticket is from 2004 and people clearly need it, who is going to step up?

Well, at least you could give this plugin a try (alos mentioned above):
​http://trac-hacks.org/wiki/BatchModifyPlugin
I does the job very well.

nkantrowitz, please add the link to the description of this ticket.

[dbw]

The BatchModifyPlugin? is close, but no cigar. I've used it quite a bit. It doesn't cut it. You have to perform a query that perfectly returns a set of results, and then you can batch modify that entire set. That's not always possible or efficient. As has been covered above, what we really need are two kinds of functionality:
(1) an ability to update all items denoted with a check (see the mock-up above). That one tweak to BatchModifyPlugin? would be great. but I asked repeatedly for that, and it appears that the developer fell off the face of the earth.
(2) also, the ability to modify each individual line item's elements without having to open each up individually is even more important. you want to be able to change the priorities etc. of multiple items simultaneously, and they shouldn't all have to be set to the same value.

[anonymous]

​http://m.tacker.org/blog/wp-content/uploads/2006/07/batchedit.png This ticket is from 2004 and people clearly need it, who is going to step up?

The ticket's from 2004, the mockup's from 2006, it would be brilliant to just build it!

[anonymous]

bump.. New trac user, old bugzilla user. Would be great to have this. I'll give BatchModifyPlugin? a try.

[anonymous]

Our company just started using Trac and this is the first thing that I would like Trac to fix. Only if my Python skill is good enough... I would have done it myself.

[agorilla@…]

I would also like to see this.

I haven't noticed any mention of a 'delete' option, but I'll add that to the request. It would be nice to be able to do a query, and select a group of tickets to delete - this could be handy in many situations: dead project, project relocated, spam, etc.

[anonymous]

I vote for this one too.

[kscharpf@…]

I just downloaded and installed ​http://trac-hacks.org/wiki/BatchModifyPlugin last week, and it works great. It allowed me to change the milestones for a whole bunch of tickets in one go, and it also has the ability to only apply the change to some of the items selected. It was a real time saver!

[ischenko@…]

Opened for 4 years...Trac's development is disappointing at times. Either reject it or implement it. pls pls.

[anonymous]

I had installed the batch modify plugin, but still i cant able to see any check box for the tickets in custom query. Do i need to update anything ?

[Sivaprakash]

can u pls tell me a solution for this

[sivaprakash@…]

need to fix this in a day

[anonymous]

Come on 4 years and still nothing!

[anonymous]

Replying to anonymous:

Come on 4 years and still nothing!

If you need it so badly you can do it. Take a look at the ticket-ninja branch if you're interested.

[rblank]

Closed #7583 as a duplicate.

[anonymous]

A good suggestion and very useful for project leaders. If there is a hack for it why not implement the hack as a core module?

[anonymous]

+1 for this. Been using this feature for years in an in-house system. No longer work there and would love this. I can try the plug in, but would be nice if it was core.

Otherwise this system is has some pretty nice sweet spots.

[natethelen]

I would love to see this, too.

[Peter Hartlén]

I really need this too, isn't it possible to add the Batch-plugin to the standard build?

[cboos]

The ​TracHacks:BatchModifyPlugin plugin seems reasonably small and clean.

Once the "pluggability" part of the code gets stripped out and the batch editing functionality gets integrated in the custom query module itself, the change should really be small for to the added value it would bring.

So I think it's indeed a good idea for the next major version. Patch welcomed ;-)

[CuriousCurmudgeon <meeker.brian@…>]

I started maintaining the ​TracHacks:BatchModifyPlugin a couple of months ago. The code is indeed small. A large chunk of it is related to plugging into the Custom Query page.

Some improvements are needed before integrating it into the next major version though. The big one is that it does not integrate with email notifications and the timeline. These are needed to make it seamless with the rest of Trac. If you know of other enhancements that would be needed before including it in Trac please add them ​here.

[cboos]

Thanks Brian for showing interest in this!

Instead of discussing the integration of this feature on TracHacks, I'd prefer to see a TracDev/Proposals/BatchModification page here, discussing the approaches, and then eventually a sandbox branch when the patches start to look promising ;-)

The integration with e-mail notifications 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.

But I wonder if a specific interface (or extra method to the IResourceChangeListener interface) wouldn't be more appropriate here, like it would be for other cases of batch modifications, for things like #4582 and #5658, or the batch WikiRename feature, see ticket:4412#comment:8.

That way, this could ideally result in one entry in the timeline for a batch change, and to one notification. Not sure if this can be done easily with the current data model, but the GenericTrac model already takes this into account (one changeid per change, with one set of metadata for the change, and then all resources modified during the batch change share that changeid).

[CuriousCurmudgeon <meeker.brian@…>]

Sorry for dropping off the planet after initially posting. I created a proposal page: TracDev/Proposals/BatchModification. I'm not very familiar with the Trac codebase outside of what I've needed for the current plugin, so it will take some time for me to get familiar with things.

[cboos]

As I just noted in the above Wiki page, I think you have now a good starting point to try to integrate the functionality in Trac core.

[Brian Meeker <meeker.brian@…>]

This is looking good for 0.13 now. It is implemented in my ​branch on github.

[cboos]

Replying to cboos:

... this could ideally result in one entry in the timeline for a batch change,

As this would also be useful for consolidating the ticket change events after a milestone delete + retarget (see e.g. timeline:2010-09-10), we could simply do this at the level of the ticket timeline provider, merging in one single "batch change" event all the change events having the same (date, author, message). In practice, now with usec timestamps, checking the date should be enough. The link for such an event would be a "ticket list" (i.e. #7639,8699,9018... the affected tickets).

[andres.riancho@…]

+1 on this! Its a must have feature!

[rblank]

Anyone wants to take this up and review the branch mentioned in comment:61? Jun? Otherwise, we should move this to 0.14.

[jomae]

Replying to rblank:

Anyone wants to take this up and review the branch mentioned in comment:61? Jun? Otherwise, we should move this to 0.14.

I pulled the branch to my repository, ​https://github.com/jun66j5/trac/compare/t525-batch-modify, and reviewed with TracDev/Proposals/BatchModification.

I think that we should move it to 0.14.

• When many tickets is modified by batch-modify;
  • It will send ticket notification mail each modified ticket. A summarizing mail is needed.
  • Many ticket-change events will be shown on timeline page. A summarizing event is needed.
• DB Api:
  • @with_transaction(env) is used. Change to with env.db_transaction as db:.
• Permission:
  • A user with TICKET_ADMIN cannot use batch-modify. If TICKET_BATCH_MODIFY is explicitly granted, a user can use it.
  • TICKET_ADMIN should be enough, not TICKET_BATCH_MODIFY.
• Others:
  • Should clean up the indents in trac/htdocs/js/query.js and trac/ticket/templates/batch_modify.html.

[Oleg Frantsuzov <franoleg@…>]

Even though I'll be really happy to see batch modification integrated into Trac, I must say it's too early for this code to be integrated. I believe the problem described in ​#TH7709 and in the following quote from TracDev/Proposals/BatchModification is not addressed yet.

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)

We have custom workflow in our Trac which includes several states that have resolutions (committed, resolved and closed). We had to patch BatchModifyPlugin because it does not respect custom workflows and forcibly sets ticket state to closed whenever a resolution is set, and removes the resolution when the ticket state is set to something else than closed. This is obviously plain wrong with our workflow (and similar ones). While this is not often the case, I believe that there should be no discrepancy in how workflows are treated in Trac.

As I can see in the integration branch (​batch.py), the offending implementations of _check_for_resolution / _remove_resolution_if_not_closed are still there. This ought to be addressed in a more generic manner.

[psuter <petsuter@…>]

I updated this a bit:

• Merged trunk (specifically [10153])
• Cleaned up (all?) indents etc.
• Fixed TICKET_ADMIN
• Used env.db_transaction as db
• Used action controllers for status changes

You can see the changes on ​bitbucket (Sorry, I'm not too familiar with git and may have messed it up. I hope you all don't mind too much.)

[shiva <shiva@…>]

Hi,

Having championed for tract for some its most appealing and obvious benefits to our engg. team, it is of concern that I have to defend the missing batch update functionality to them.

I find it a bit surprising that in 7 years we have not felt the need to integrate just a basic functionality into main product. This is a functionality that found by default in almost any ticketing system that i have come across ( Clarify, Eventum etc. ). I sincerely request that the priority of this issue be raised.

I am going to try the batch update plugin in whatever state is in and definitely not going to resort to changing the DB even if i have to allocate resources solely to update the 1000+ tickets that require the change. In a organisation with auditing concerns, I am left with no other choice.

Thanks for all your work, It has been pleasurable experience to move to Trac from a host tools previously used to accomplish what this does for us.

Regards,
Shiva

[psuter <petsuter@…>]

As far as I can tell the remaining open issue here is the missing support for batch notifications and batch timeline events.

I'm trying to summarize the options:

Batch ticket modify timeline events could either be detected in the ticket timeline provider somehow, or a new batch change listener interface method could be introduced on the planned IResourceChangeListener or the existing ITicketChangeListener.

For batch email notifications there are even more possibilities:

• Move the TicketNotifyEmail calls to a ITicketChangeListener (#7758), call these change listeners on batch modify, using the normal ticket_changed method and detect batch modifications in that listener somehow.
• Use a new batching ITicketChangeListener method instead.
• Use the planned IResourceChangeListener instead.
• Simply directly call TicketNotifyEmail from the batch modification code.
• Wait for the integration of the announcer plugin.

In any case the TicketNotifyEmail (or Announcer) needs:

• a new email template / formatter for such batch notifications
• logic to find the recipients / subscribers from all modified tickets

(Or actually, it seems to me creating a new BatchTicketNotifyEmail subclass of NotifyEmail would work better.)

---

Since IResourceChangeListener, Announcer and #7758 all seem to be stalled themselves, it might make sense to move forward using batch timeline event detection and a direct call of a new BatchTicketNotifyEmail here. This is admittedly not a very pretty or forward thinking solution.

Alternatively this could be integrated for now without batching up timeline events and without sending any batch notification mails at all. (Precedent for this behavior would be milestone delete and retarget tickets.)

Any opinions on this? Are there other open problems or solutions I missed? (And is anyone else still planning to work on this?)

[anonymous]

I would be grateful if this was implemented in the next release, I am not too concerned with the mass e-mail / timeline issue and that could follow in the future, I do however have projects that need to do large updates (for example assign lots of tickets to a milestone) which would be very useful. The precendent with deleting and retarget with the milestone completion is acceptable to me.

[anonymous]

Can I please vote for this feature also.