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.