Edgewall Software

Opened 10 years ago

Closed 10 years ago

Last modified 10 years ago

#10871 closed enhancement (fixed)

Improve custom list fields to behave like keywords

Reported by: Peter Suter Owned by: Peter Suter
Priority: normal Milestone: 1.0.1
Component: ticket system Version:
Severity: minor Keywords:
Cc: Branch:
Release Notes:

Custom text fields with format=list now behave more like keywords:

  • Batch modify now also allows adding and removing entries.
  • Property diffs now also render the entries added and removed.
  • Querying multiple entries now also searches them individually.
API Changes:
Internal Changes:


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.

Attachments (2)

T10871-custom-list-field-keywords-features.patch (6.3 KB ) - added by Peter Suter 10 years ago.
T10871-custom-list-field-keywords-features-1.0.1.patch (6.4 KB ) - added by Peter Suter 10 years ago.

Download all attachments as: .zip

Change History (8)

comment:1 by Peter Suter, 10 years ago

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?)

comment:2 by Christian Boos, 10 years ago

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…

comment:3 by Peter Suter, 10 years ago


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?

in reply to:  3 comment:4 by Christian Boos, 10 years ago

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…

comment:5 by Peter Suter, 10 years ago

Resolution: fixed
Status: newclosed

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

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

comment:6 by Peter Suter, 10 years ago

Owner: set to Peter Suter
Release Notes: modified (diff)

Modify Ticket

Change Properties
Set your email in Preferences
as closed The owner will remain Peter Suter.
The resolution will be deleted. Next status will be 'reopened'.
to The owner will be changed from Peter Suter to the specified user.

Add Comment

E-mail address and name can be saved in the Preferences .
Note: See TracTickets for help on using tickets.