Edgewall Software

Ticket #525 (assigned enhancement)

Opened 4 years ago

Last modified 4 weeks ago

Batch Modification Functionality

Reported by: anonymous Owned by: nkantrowitz
Priority: normal Milestone: 1.0
Component: ticket system Version: 0.7.1
Severity: normal Keywords:
Cc: m@…, pkou@…, rjack@…, mat@…, david@…, erikand@…, garyo@…, chad@…, henko@…

Description (last modified by cboos) (diff)

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.

Attachments

Mantis01.png (57.6 KB) - added by cboos 2 years ago.
Screenshot added on behalf of Steven Martins (illustrate how the Mantis user interface for this feature looks like)
Mantis02.png (17.9 KB) - added by cboos 2 years ago.
Screenshot added on behalf of Steven Martins (illustrate how the Mantis user interface for this feature looks like)

Change History

  Changed 4 years ago by daniel

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

  Changed 4 years ago by brianhv

  • milestone set to 0.9

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.

  Changed 4 years ago by cmlenz

  • owner changed from jonas to cmlenz
  • status changed from new to assigned

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.

  Changed 4 years ago by cmlenz

  • milestone changed from 0.9 to 1.0

  Changed 3 years ago by cmlenz

  • component changed from general to ticket system

  Changed 3 years ago by Russell Hind <rhind@…>

  • cc rhind@… added

  Changed 3 years ago by cboos

  • description modified (diff)

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

  Changed 3 years ago by Markus Tacker <m@…>

  • cc m@… added

  Changed 3 years ago by anonymous

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

  Changed 3 years ago by anonymous

  • cc pkou@… added

  Changed 3 years ago by anonymous

  • cc rjack@… added

  Changed 2 years ago by anonymous

  • cc mat@… added

  Changed 2 years ago by cmlenz

#3388 has been marked as duplicate of this ticket.

Changed 2 years ago by cboos

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

Changed 2 years ago by cboos

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

  Changed 2 years ago by 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.

  Changed 2 years ago by 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)

follow-up: ↓ 18   Changed 2 years ago by 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

  Changed 2 years ago by 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.

in reply to: ↑ 16   Changed 2 years ago by 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.

  Changed 2 years ago by 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?

  Changed 2 years ago by anonymous

Here is something I am working on...

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

-Ashwin

  Changed 2 years ago by anonymous

  • cc david@… added

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?

  Changed 2 years ago by 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.

  Changed 2 years ago by 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.

  Changed 22 months ago by anonymous

#4727 marked as duplicate.

  Changed 21 months ago by anonymous

  • cc erikand@… added

  Changed 19 months ago by anonymous

  • cc garyo@… added

  Changed 19 months ago by chad@…

  • cc chad@… added

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.

  Changed 18 months ago by nkantrowitz

  • owner changed from cmlenz to nkantrowitz
  • status changed from assigned to new

  Changed 18 months ago by nkantrowitz

  • status changed from new to assigned

  Changed 14 months ago by henko@…

  • cc henko@… added

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.

  Changed 13 months ago by sid

#6257 was marked as duplicate of this ticket.

  Changed 10 months ago by eblot

#6715 was marked as a duplicate of this ticket

follow-up: ↓ 34   Changed 10 months ago by 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?

in reply to: ↑ 33   Changed 10 months ago by 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.

follow-up: ↓ 36   Changed 10 months ago by 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.

in reply to: ↑ 35   Changed 10 months ago by 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!

  Changed 7 months ago by anonymous

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

  Changed 6 months ago by rhind@…

  • cc rhind@… removed

  Changed 5 months ago by 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.

  Changed 5 months ago by 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.

  Changed 4 months ago by anonymous

I vote for this one too.

  Changed 4 months ago by 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!

  Changed 4 months ago by ischenko@…

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

  Changed 3 months ago by 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 ?

  Changed 3 months ago by Sivaprakash

can u pls tell me a solution for this

  Changed 3 months ago by sivaprakash@…

need to fix this in a day

follow-up: ↓ 48   Changed 2 months ago by anonymous

  • priority changed from normal to highest

Come on 4 years and still nothing!

in reply to: ↑ 47   Changed 2 months ago by anonymous

  • priority changed from highest to normal

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.

  Changed 4 weeks ago by rblank

Closed #7583 as a duplicate.

Add/Change #525 (Batch Modification Functionality)

Author



Change Properties
<Author field>
Action
as assigned
as The resolution will be set. Next status will be 'closed'
to The owner will change from nkantrowitz. Next status will be 'new'
 
Note: See TracTickets for help on using tickets.