* Betr.: " Re: [tryton] Zero-price items" (Thu, 12 May 2011 13:24:01 +0200):
> * Cédric Krier [2011-05-12 12:58 +0200]:
>
> >> >You did not understand.
> >> >I mean the current "required" parameter on Float fields means "!=
> >> >0". And in this possible migration we will replace the meaning of
> >> >"required" by a new parameter "nonzero". And I think it will be a
> >> >good idea to have as default value for the new "required"
> >> >parameter "True" like that we keep the same behavior by default.
> >>
> >> You're not clear. What do you mean ? You want to rename "required"
> >> to "nonzero" for numerical fields ? If so then this will no settle
> >> the situation.
> >>
> >> Or maybe you want to add a nonzero parameter. Which does not seems
> >> useful to me.
> >
> >Again, required attribute on Float fields doesn't mean "not null". It
> >means "non zero". And this feature is important because we used in
> >many places (I counted 45 fields using this feature) where we don't
> >allow zero as value.
>
> I know this is not the right name.
>
> >So we can rename it into nonzero if we add a required attribute that
> >means "not null".
>
> That's what I understood. As I said only renaming will not change the
> situation, only make it worse. I like the idea of having the required
> attribute having the usual meaning and adding the client side
> validation.
>
> >> >For me, there is no ambiguity once you accept that a Float field
> >> >will always have a float value.
> >>
> >> A Float field should only have a numerical value if it is required
> >> to do so. Do you expect Date Field to always have a date value so
> >> that you can do all kind of date operation on them ? Do you expect
> >> Many2One field to have a non NULL value ? No, unless those fields
> >> are required.
> >>
> >> I think that it should work the same way for numerical fields.
> >
> >There is also a big issue when accepting null in float field, it is
> >that SQL doesn't SUM (or other operation) between float and NULL.
>
> Indeed.
> But this could be fix in numerous way.
>
> >> >In the business application world, I really think there are few
> >> >places where we need to deal with "unknown" values.
> >>
> >> Every non required field could be "unknownable".
> >
> >But this is not possible for almost all the fields (see the list).
>
> The goal of this change is to remove one ambiguity. I know that it is
> not possible to do it for all fields.
>
> >> If you want them to have a value (whatever it is) then the field
> >> must become required.
> >
> >What I want to say is that it is a feature not very important and
> >compared to the time it will take to implement/test, there is really
> >a lot of other stuffs to do.
>
> Maybe it is not the most important, but there is a small conceptual
> problem there.
Whether small or not, I think it is important;). JFTR: we had to eliminate the
'required' on unit_price already long time ago, because for us (in Germany)
there are many use cases for invoice lines with amount 0.
I like very much the idea to have 'required' and 'nonzero'.
--
Mathias Behrle
MBSolutions
Gilgenmatten 10 A
D-79114 Freiburg
Tel: +49(761)471023
Fax: +49(761)4770816
http://m9s.biz
UStIdNr: DE 142009020
PGP/GnuPG key availabable from any keyserver, ID: 0x8405BBF6
signature.asc
Description: PGP signature
