Batch Modification of Custom Text Area

[beardedbrawler@…]

Text areas are excluded from batch modification (TracBatchModify#Excludedfields).

There may be utility in allowing batch modification of custom text areas in a case like the following:

There is a custom final resolution text area in a ticket. A group of tickets are resolved by updating registry settings. A .reg file updates all the required reg settings. The final resolution is running the reg file on systems to resolve the group of tickets.

Batch modifying the text area would make this more streamlined instead of having to go to each individual ticket to enter the info into the text area.

[beardedbrawler@…]

looking at [11066] this enhancement may be as easy as removing the field type exclusions for textareas from batch.py and batch_modify.html.

[beardedbrawler@…]

Replying to beardedbrawler@…:

looking at [11066] this enhancement may be as easy as removing the field type exclusions for textareas from batch.py and batch_modify.html.

I've went ahead and made this change on my instance and the fields of type textarea now show as selectable options when doing a batch modify. However, the box in which to enter data does not display as one would expect. Trying to find out how to make this work as expected.

[Stephan H.]

I would appreciate a fix on this one.

My use case is the following:
Prior to accepting that tickets remain open for a specific milestone, the change control board (CCB) needs to evaluate each and every ticket.
This evaluation also contains a final evaluation_resolution which is saved in a custom textarea.
The CCB meets to review and approve all of these evaluations and their evaluation_resolutions.
Typically there are two or three different evaluation_resolutions (all lenghty text).

Thus it would really streamline my workflow if I could just select all applicable tickets in a list and then update the evaluation_resolution for all of these tickets at once (via batch modify) instead of entering the same text multiple times.

[Christian Boos]

undecided means we really leave it open to the community… If you can't do it yourself, perhaps you can find someone who can develop a patch (with tests, see PatchWelcome), and then we could consider it. Otherwise, the only realistic expectation about a ETA would be that one of the maintainers feels at some point the same need (and no, going from normal text to bold, and from bold to SCREAMING_CASE won't help ;-) ).

[sarev_of_aona@…]

Thanks Christian. I fully appreciate the need for the community to step up and help with this and have no complaints with that sentiment.

Here's another use case to hopefully explain the need for this. Maybe this will inspire someone in the community… :)

Aside from a conventional use of Trac within our organisation, we use another instance of Trac to record the progress of widgets through production, from inception through to installation. Each widget has a ticket (yes, we're low volumes here at the moment!), each production step is a milestone. We've got a custom field for "firmware version" which could be a drop-down but we'd have to edit "trac.ini" for every new release that we create, which is a little impractical. Also, that menu is just going to keep getting longer and more clunky.

So I settled upon using a textarea (the version isn't just a number; it includes a git hash and other stuff). It's a real bummer that I can't batch-modify this field because every time we deploy an upgrade to the installed widgets, we'd have to manually update every ticket one at a time. This clearly doesn't scale!

So we're trapped between having an unwieldy drop-down menu that requires admin ssh access to add things to - but we can batch modify - or a textarea that gives us the right flexibility but we can't batch modify. Darn!

After having gone through all the tickets adding the firmware version as a textarea, I'm going to have to revert to a drop-down because the lack of batch modify for textareas is a killer.

[Ryan J Ollos]

Replying to sarev_of_aona@…:

So we're trapped between having an unwieldy drop-down menu that requires admin ssh access to add things to - …

TracTicketsCustomFields can be added through the web ui using ​CustomFieldAdminPlugin, which should be added to Trac in the near future (#11469). ​XmlRpcPlugin would be another solution for adding fields remotely, but it appears it doesn't support custom fields.

[Stephan H.]

Replying to Christian Boos:

…and no, going from normal text to bold, and from bold to SCREAMING_CASE won't help ;-) ).

Thanks for your comment - unfortunately I still don't have a solution I could offer here.

As for my formatting: I just intended to improve readability.
I am perfectly aware, that contributions to this project are always voluntary work, which I really do appreciate (meant to scream 'THANKS TO ALL' this time :)).

[Ryan J Ollos]

#13353 closed as a duplicate.