[PATCH] Optional case-insensitivity for tag cloud and tag query

[Ben Allen]

Overview

Tickets #4200 and #4799 partially address the ability to make tags case-insensitive. However, neither of those solutions is complete. The attached patch enhances the TagsPlugin with the ability to make tag queries and the tag cloud case-sensitive or case-insensitive. These case-insensitivity enhancements are divided into three categories and each is individually configurable by the user. If these new settings are left to their defaults, the behavior should be identical to the current behavior (which should avoid disrupting any existing installations).

Trac.ini Settings

The following trac.ini settings are used to control this feature:

[tags]
# Treat tag queries as case-sensitive (default=true)
case_sensitive_queries = false
# Use a case-sensitive sort for the tag cloud (default=true)
cloud_sort_by_case = false
# Cloud view should combine tags that differ only in case (default=false)
cloud_combine_similar = true

Test Case

Say you have three tickets. Ticket #1 has the keyword 'write', ticket #2 has the keyword 'WRITE', and ticket #3 has the keyword 'Write'. The system also has other tickets/wiki pages with various other tags/keywords.

The default behavior of the tag cloud is to list all three tags individually. 'WRITE' and 'Write' would be listed in the first half of the tag cloud with other tags that start with capital letters, and 'write' would be listed near the end of the tag cloud. Clicking on one of the tags would take you to a tag query page that lists only the ticket that uses that particular capitalization scheme for the keyword.

If you set the 'case_sensitive_queries' option to 'false', then clicking on any of the "write" tags would take you to a tag query page that lists all three tickets.

If you set the 'cloud_sort_by_case' flag to 'false', then the tag cloud would list 'WRITE', 'Write', and 'write' next to each other.

If you set the 'cloud_combine_similar' flag to 'true', then there would only be a single "WRITE" tag listed instead of three. Hovering the mouse over that unified tag would display a tooltip showing a count of three.

Potential Configuration Problem

If the user sets 'cloud_combine_similar' to 'false' and 'case_sensitive_queries' to 'true', then there can potentially be tags that aren't accessible from the tag cloud. Querying for those tags individually will still work, however.

[Ben Allen]

Patch implementing the above-described functionality

[Ben Allen]

A few details:

This was developed on Trac 0.12 running r10135 of the TagsPlugin. My Trac uses a mySQL database. Since part of this patch involves tweaking one of the SQL queries, someone will want to test it on PostgreSQL, etc to make sure it works there as well.

Python is still relatively new to me so there may be more efficient ways to implement some of this. In particular, I'm pretty sure that the TagSystem._consolidate_taglist function is more complicated than it needs to be. Someone with a bit more Python-fu may be able to clean it up.

I forgot to mention it explicitly in the ticket, but parts of this patch originated as parts of the patches associated with #4200 and #4799.

[Steffen Hoffmann]

Oh, I've just been pointed at this ticket.

Since you've been well aware of both related tickets, it would have helped yourself in getting recognized to drop a comment regarding this work here too.

Meanwhile I started implementation with #4799 similar, but not identical to your changes. Will have a look. Any comment at [10736] will be appreciated. Meanwhile I'll think about the way to proceed with these three tickets covering similar, but only partly overlapping issues. Your work is certainly the most comprehensive one (Thanks!) and I'd like to have you around for discussion and testing.

[Ben Allen]

Sorry about that, I've gotten accustomed to having TracBacksPlugin generate ticket cross-references for me and I forgot that trac-hacks doesn't have that one running :-(

My patch here should fully overlap ticket:4799, plus pull in the "case-sensitive queries" portion of ticket:4200 (at least that's what my original intention was).

Your r10736 looks like it essentially does the same thing that I did in my patch when cloud_sort_by_case is set to false. The main difference seems to be that you added a caseless_sort parameter to the render_cloud function, and I moved render_cloud inside class TagWikiMacros to allow it to access the value directly instead of using a new parameter (essentially the same thing).

If you wanted to use the rest of my changes, it looks like it shouldn't be too hard to integrate them, even after r10736. Essentially, keep my changes to api.py, ticket.py, and query.py, and ignore my changes to macros.py (since they're superseded by r10736).

[Steffen Hoffmann]

Replying to AllenB:

Your r10736 looks like it essentially does the same thing that I did in my patch when cloud_sort_by_case is set to false. The main difference seems to be that you added a caseless_sort parameter to the render_cloud function, and I moved render_cloud inside class TagWikiMacros to allow it to access the value directly instead of using a new parameter (essentially the same thing).

Not quite, because it looks like this is related to thread-safe macro design, see #10636.

[Steffen Hoffmann]

In 13815:

TagsPlugin: Completing preparation for v0.7 release.

Availability of that code as stable, tagged release
closes #2429, #3359, #3610, #3624, #3677, #3754, #3864, #3947, #3983, #4078, #4277, #4503, #4799, #5523, #7787, #7857, #8638, #9057, #9058, #9059, #9060, #9061, #9062, #9063, #9149, #9210, #9521, #9630, #9636, #10032, #10416, #10636, #11096, #11147, #11152, #11274, #11302, #11658 and #11659.

Additionally there are some issues and enhancement requests showing progress,
but known to require more work to resolve them satisfactorily, specifically
refs #2804, #4200, #8747 and #9064.

Thanks to all contributors and followers, that enabled and encouraged a good
portion of this development work.