Batch Modify add/remove keyword: Empty change

[anonymous]

Example scenario: Assume that you want to cleanup the keywords and change wikimacros to wiki-macros:

• Go to query:keywords~=wikimacros page.
• Check all tickets.
• Open Batch Modify section.
• In Add Field dropdown select Keywords.
• Select add / remove.
• Enter add: wikimacros remove: wiki-macros.
  • (This is a user error. Intended was the inverse: add: wiki-macros remove: wikimacros.)
• Click Change tickets button.

• Now navigate to one of the changed tickets.
• Observed behavior: A change history entry was added to the ticket, with a yellow box indicating the change to the keywords field; but there is no actual change, the keywords have remained as they were.
• Expected behavior: I'm unsure. Maybe this is working as intended? Maybe the ticket should remain unchanged? Maybe there was actually a (subtle) change, but it is not shown clearly? Maybe it should warn that no tickets actually match the removed keyword?

[anonymous]

It looks like this:

[Ryan J Ollos]

I have tested with 1.0-stable, 1.2-stable and trunk, and cannot reproduce. What is your Trac version?

[anonymous]

According to Trac "About" page : "Trac 1.3.3dev"

According to svn info: "URL: ​https://svn.edgewall.org/repos/trac/trunk" / "Revision: 16660"

Unfortunately the Trac demo sites don't seem to allow testing Batch Modify functionality.

[Ryan J Ollos]

Would you mind testing with 1.3.5? It was released a few days ago.

[Ryan J Ollos]

Also, please post your list of installed plugins.

[anonymous]

I can not reproduce the issue either, even on the same site as it happened once.

[Ryan J Ollos]

Is there anything unique about the history of the Trac site? What version did you start with, and how long has the environment existed? Did you import tickets using a TracImport plugin?

Directly modifying the database with replacement wikimacros → wikimacros (trailing whitespace), and then batch modifying like you did, I get similar, but not exactly the result you showed:

[Ryan J Ollos]

Running a query on your database for those tickets would be helpful. Something like:

../tracenvs/proj-1.3/db/trac.db> SELECT * FROM ticket_change WHERE ticket_change.oldvalue
                                 LIKE "%wikimacros %"
+--------+------------------+--------+----------+-------------+------------+
| ticket | time             | author | field    | oldvalue    | newvalue   |
+--------+------------------+--------+----------+-------------+------------+
| 12     | 1563572395766077 | user1  | keywords | wikimacros  | wikimacros |
| 61     | 1563572395766077 | user1  | keywords | wikimacros  | wikimacros |
| 83     | 1563572395766077 | user1  | keywords | wikimacros  | wikimacros |
| 94     | 1563572395766077 | user1  | keywords | wikimacros  | wikimacros |
+--------+------------------+--------+----------+-------------+------------+
4 rows in set
Time: 0.010s

For your database, the following might be more useful: SELECT * FROM ticket_change WHERE field="keywords" AND ticket=<id>, with <id> replaced by the ticket from your comment:1 screen capture.

[Ryan J Ollos]

Proposed refactoring: [a16576607/rjollos.git]. It won't affect the behavior reported in this ticket, just some code I noticed could be improved.

[anonymous]

sqlite> SELECT * FROM ticket_change WHERE field="keywords" AND ticket=3427;
3427|1538576096953185|anonymous|keywords|python OpenSSH tox|python OpenSSH tox wikimacros
3427|1563349480998871|anonymous|keywords|python OpenSSH tox wikimacros|python, OpenSSH, tox, wikimacros
3427|1563349905915175|anonymous|keywords|python, OpenSSH, tox, wikimacros|python, OpenSSH, tox, wiki-macros

The second entry seems to be the case above. (And the third what was intended in the first place, with the keywords switched around correctly.)

Maybe the adding of , is what confuses the issue?

[Ryan J Ollos]

Replying to Ryan J Ollos:

Proposed refactoring: [a16576607/rjollos.git]. It won't affect the behavior reported in this ticket, just some code I noticed could be improved.

Additional refactoring in log:rjollos.git:t13179_refactoring.

[Ryan J Ollos]

comment:11 changes committed in r17000.

[Ryan J Ollos]

Replying to anonymous:

Maybe the adding of , is what confuses the issue?

Thanks, will investigate.

What is the history of the site? What version did you start with, and what has been the progression of upgrades, as best you can remember?

[anonymous]

Best guess it probably started with 0.11.X and was upgraded via 0.12.X, 0.13.X, 1.0.X, 1.1.X, 1.2.X, 1.3.X as needed. I don't know how I could check the exact upgrades / versions.

[Ryan J Ollos]

Reproduced by creating a ticket with keywords python OpenSSH tox wikimacros. Followed by batch modification:

• Add: wikimacros, Remove: wiki-macros

Note the trailing comma for the Add value.

proj-1.3/db/trac.db> SELECT oldvalue,newvalue FROM ticket_change WHERE ticket=101
+-------------------------------+----------------------------------+
| oldvalue                      | newvalue                         |
+-------------------------------+----------------------------------+
| python OpenSSH tox wikimacros | python, OpenSSH, tox, wikimacros |
| 1                             |                                  |
+-------------------------------+----------------------------------+
2 rows in set
Time: 0.010s

On 1.0-stable, the ticket change is:

On 1.2-stable:

On trunk:

[Ryan J Ollos]

I noticed we allow duplicate keywords (same behavior on 1.0-stable). To avoid duplicates, I propose that we define a separator (could be configurable using an option [ticket] list_separator), parse the list field with separators ;,\s on ticket save, store the values in the database as a whitespace-seperated string, and join the fields using the defined separator when rendering. I don't plan to propose any of those changes in this ticket.

[Ryan J Ollos]

Does ; need to be localized?: trunk/trac/ticket/web_ui.py@17000:1787#L1775​

[Ryan J Ollos]

Proposed changes in rjollos.git:t13179_list_change. The changes should restore the behavior from 1.2-stable.

[Ryan J Ollos]

Replying to Ryan J Ollos:

I noticed we allow duplicate keywords (same behavior on 1.0-stable).

⇒ #13185.

[Ryan J Ollos]

comment:18 changes committed in r17003.