On 12/05/11 10:25 +0200, Nicolas Évrard wrote: > >I too find myself in need of being able to add zero-priced invoice lines > >to invoices from time to time - which is not supported by tryton > >out-of-the-box. > > > >This makes me wonder if perhaps the whole required state machinery needs > >to be able to allow zero values on numeric fields to satisfy the > >requirement. I'm well aware of where this comes from: in python numeric > >values of zero evaluate to False. However, is a business context an > >explicit zero-amount is *not* the same as an unspecified amount, or in > >other words: 0 is not False, only False is False. > > I am a strong supporter of this idea. > We are discussing it right now in fact. ;) > > I will let Cédric explain his view on this subject but I think that > there is a difference between not having the information and knowing > that this information is 0.
We designed the application in the way that if you use a Float (Integer,
Numeric) field you are sure to have a float value (not False).
In other terms, all numeric value are "not null" in the database.
We did this because we thought it makes the development easier and also
because we did not find clear way in the client interface to distinct both
cases.
I think the problem is bigger than that there is some kind of fields where it
will be possible to get a null value (which mean I don't know) and others not.
Possible fields which can handle unknow values:
- Date/DateTime
- Integer/Float/Numeric (if we change it)
Others:
- Char/Text (no difference to display between '' and False/None)
- Many2One (not possible to have unknow value as False/None is no link)
- One2Many
- Many2Many
- Boolean
- Binary
- Selection (we need to put a empty value in the list)
There is many more type of fields where the "unknown" value is not supported.
So for me, there is no problem to implement the "unknown" value in Float
fields but we need to keep the "not zero" mechanism and perhaps keep the
default value for required True.
But as we already need to keep the "unknow" information about a many other
kind of fields into an other field. For me I don't see the need to make this
change. We can always fix the (not so often) cases of "unknown" value for
Float with a Boolean field that will show/hide the field.
--
Cédric Krier
B2CK SPRL
Rue de Rotterdam, 4
4000 Liège
Belgium
Tel: +32 472 54 46 59
Email/Jabber: [email protected]
Website: http://www.b2ck.com/
pgpZ00rh2yc0F.pgp
Description: PGP signature
