Batch-Modify fails on keywords and cc fields

[helge.wiethoff@…]

Hi all,

i am not able to use TracBatchModify for keywords or cc fields in Trac 1.0.12. There is no error message. Other fields (no list fields) are handled well.

The Debug Log is not very revealing:

2016-09-13 12:35:02,140 Trac[main] DEBUG: Dispatching <RequestWithSession "POST '/batchmodify'">
2016-09-13 12:35:02,141 Trac[session] DEBUG: Retrieving session for ID u'xxx'
2016-09-13 12:35:02,145 Trac[main] DEBUG: Negotiated locale: None -> de
2016-09-13 12:35:05,046 Trac[main] DEBUG: Dispatching <RequestWithSession "GET '/query?status=assigned&status=closed&status=new&status=reopened&col=id&col=summary&col=status&col=type&col=priority&col=milestone&col=component&order=priority'">

Cheers, Helge

[Jun Omae]

Good catch. Reproduced on demo-1.0. That's bad.

Adding blah@localhost to cc and #12585 to keywords of #4000,#4002 doesn't work.

[Jun Omae]

Ah, my bad. It seems this issue is introduced in [14724] (#12364).

Could you please try the following patch?

trac/ticket/batch.py

@@ -167 +167 @@
                 t = Ticket(self.env, int(id))
                 _values = new_values.copy()
                 for field in list_fields:
-                    if field in new_values:
+                    mode = req.args.get('batchmod_value_' + field + '_mode')
+                    if mode:
                         old = t.values[field] if field in t.values else ''
-                        new = new_values[field]
-                        mode = req.args.get('batchmod_value_' + field +
-                                            '_mode')
+                        new = req.args.get('batchmod_value_' + field +
+                                           '_primary')
                         new2 = req.args.get('batchmod_value_' + field +
                                             '_secondary', '')
                         _values[field] = self._change_list(old, new, new2,

[Jun Omae]

I noticed another issue in batch-modify feature with list format of custom fields.

1. Custom fields have the following:

   [ticket-custom]
   foo = text
   foo.format = list
   foo_secondary = text
   

2. Visit query view and select some tickets.
3. Select foo field in Add Field drop down in batch-modify form.
4. Select add / remove in drop down and enter blahblah to remove text field.
5. Submit, foo_secondary field is wrongly updated with blahblah.

Confirmed with Trac 1.0.10 (prior to [14724]) and 1.0.13.

[anonymous]

Hi Jun!

The patch works like a charm :) Thank you very much. But there is a minor problem with the email-notifaction: When email notification is enabled, the batch modification is not recognized:

MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
From: Trac <trac@example.com>
X-Mailer: Trac 1.0.13, by Edgewall Software
X-Trac-Project: Trac
Date: Wed, 14 Sep 2016 08:25:51 +0000
Reply-To: <trac@example.com>
Subject: [Trac] Batch modify: #2471


Batch modification to #2471 by wiethoff:


--
Tickets URL: <https://trac.example.com/it/query?id=2471>
Trac <https://trac.example.com/it>
Trac

Again, thanks for your fast reply.

[Jun Omae]

Thanks for the testing!

The issue in notification by batch-modify to list fields might be related to #11271 #12174. I try to fix both this issue and #11271.

[Jun Omae]

Proposed changes for this issue and naming conflicts in [374808e87/jomae.git] (jomae.git@t12585).

batchmod_secondary_<name> would be used instead of batchmod_value_<name>_secondary to avoid the naming conflicts.

[Ryan J Ollos]

The changes work well for me.

[Jun Omae]

Thanks for the reviewing! Committed in [15157] and merged in [15158-15159].

[helge.wiethoff@…]

in my case the generated mail is still empty :-(

[Jun Omae]

Replying to helge.wiethoff@…:

in my case the generated mail is still empty :-(

That issue has been reported in #11271, not fixed yet.

[helge.wiethoff@…]

Isnt #11271 about "a better representation"? I see no output at all. Just:

Batch modification to #2541 by wiethoff:

And i thought this was fixed in [15157] but i had no luck with this patch.

[Jun Omae]

#12174 and #11271 are the same issue.

And i thought this was fixed in [15157] but i had no luck with this patch.

I know.

[Jun Omae]

Replying to Jun Omae:

#12174 and #11271 are the same issue.

And i thought this was fixed in [15157] but i had no luck with this patch.

I know.

The type of #11271 is changed to defect.

[helge.wiethoff@…]

thanks for the clarification.