Improve custom list fields to behave like keywords

[Peter Suter]

This comment reminded me that keyword-like fields (TracTicketsCustomFields#AvailableFieldTypesandOptions text format=list) do not enable all the keyword-style behavior yet:

• Batch modify does not allow adding and removing entries.
• Property changes does not use the special diff rendering.
• Querying multiple words does not search them individually.

[Peter Suter]

Would it be appropriate to also enable these things for 1.0.1?

This patch​ modifies the checks that enable special keywords features to look for text format=list fields instead, and marks keywords and cc as such fields. Does that make sense?

(Hm, sometimes field.get('type') is used instead of field['type']. Is type not guaranteed to exist?)

[Christian Boos]

Yes, I think 1.0.1 is fine for this one, as it makes the new 1.0 list format "feature complete".

The patch looks good, however I prefer the naming list_fields (as in query.py) rather than fields_as_list (you could easily imagine with such a name that its about the "fields" themselves represented as a list).

And about field.get('type'), I don't know, perhaps it's historical and they haven't always all had a type specified…

[Peter Suter]

OK, thanks for reviewing! Here's the fixed patch for 1.0.1. (And this made me realize field could be a fallback empty {}, which explains the get().)

BTW is there a difference between 1.0-stable: and 1.0.1dev: as a commit message prefix?

[Christian Boos]

Replying to psuter:

is there a difference between 1.0-stable: and 1.0.1dev: as a commit message prefix?

Well, I'm not that fond of the branch prefixes, I really think this should be visible in the commit itself (and for the timeline we could have the changeset_show_files = location setting?). I tend to use this kind of prefix more when we're close to a release, but other than that, I personally prefer to use a ticket prefix, or the module/functional area… So to answer your question, between 1.0-stable: and 1.0.1dev: I have no preferences and we have not defined a rule yet either…

[Peter Suter]

I see. From looking at the log I assumed there was some intricate system. :)

Anyway, applied in [11378]. Merged to trunk in [11379].