Opened 14 years ago
Last modified 4 years ago
#10040 new enhancement
Support for integer/float custom fields
Reported by: | pipern | Owned by: | |
---|---|---|---|
Priority: | normal | Milestone: | next-dev-1.7.x |
Component: | ticket system | Version: | |
Severity: | normal | Keywords: | patch |
Cc: | osimons, leho@…, Ryan J Ollos | Branch: | |
Release Notes: |
Adds integer and float as custom field type and query language constraints |
||
API Changes: |
Adds a 'datatype' key to the TicketSystem.fields list, which can contain string:
|
||
Internal Changes: |
Description
See http://article.gmane.org/gmane.comp.version-control.subversion.trac.devel/6561 for some discussion.
We'd like to be able to mark some custom fields as "contains integer" or "contains floating number". This would then let us sort numerically, validate user input, add an aggregation/summing feature, and so on.
We're not thinking of changing the storage type, nor, currently, the Python type that exists in the ticket.fields list. Instead, we just validate the user input and then later we can also attempt to convert the field value to the numeric type if we want to do sorting or summing.
This can fix #3080, but walks in the wrong way for FieldRefactoring.
Attachments (1)
Change History (16)
comment:1 by , 14 years ago
Release Notes: | modified (diff) |
---|
by , 14 years ago
Attachment: | numeric-fields-r10583-ticket-10040.patch added |
---|
comment:2 by , 14 years ago
Milestone: | → 0.14 |
---|
Looks very interesting, thanks! I'm not sure we will manage to get this into 0.13, as we already have the time fields to be integrated there. So I'm scheduling for 0.14 for now.
follow-up: 4 comment:3 by , 14 years ago
Looks fine, but as you don't seem to actually use or test for datatype == 'string'
, I wonder if we couldn't just leave that out of the picture and assume that if datatype
is not set or empty, it's a textual field.
comment:4 by , 14 years ago
Replying to cboos:
Looks fine, but as you don't seem to actually use or test for
datatype == 'string'
, I wonder if we couldn't just leave that out of the picture and assume that ifdatatype
is not set or empty, it's a textual field.
It's true that 'string' has nothing special happening to it. It's there mostly as documentation I suppose.
comment:5 by , 14 years ago
Cc: | added |
---|
comment:6 by , 10 years ago
Cc: | added |
---|
comment:7 by , 10 years ago
Cc: | added |
---|
comment:9 by , 10 years ago
Keywords: | bitesized added |
---|
comment:10 by , 9 years ago
Milestone: | next-dev-1.1.x → next-dev-1.3.x |
---|
comment:11 by , 8 years ago
Keywords: | bitesized removed |
---|---|
Release Notes: | modified (diff) |
Non-bitsized.
comment:12 by , 8 years ago
The proposed patch would lead errors with non-numeric string on PostgreSQL.
template1=# SELECT CAST('42' AS INTEGER); int4 ------ 42 (1 row) template1=# SELECT CAST('abc' AS INTEGER); ERROR: invalid input syntax for integer: "abc" LINE 1: SELECT CAST('abc' AS INTEGER); ^ template1=# SELECT CAST('42abc' AS INTEGER); ERROR: invalid input syntax for integer: "42abc" LINE 1: SELECT CAST('42abc' AS INTEGER); ^
Add validation/use of numeric (custom) fields