zero could be a value

[rycks]

fix #32615 (i hope) :-)

there is a race condition with zero because empty(0) is true ... then we did not display the value

[rycks]

please wait i forget to do the "update/edit" part of the problem

but on clic on 'update' the value will become ''

[rycks]

the last commit do the job for edit step ... but there is something funny now when i try to update the row with "code zero" :

[hregis]

@rycks maybe the unique key for the field

[rycks]

@hregis No ... that is really a test :

now i have to find the reason why zero is prohibited and why some dictionnaries use that number :-)

[rycks]

@hregis ok but tinyint could store (int)0 as a value ... no ?

i dig into commit history, here is the origin of the test: 20 years before :-)

thanks to comments we could understand that race condition : zero and '' could not be desactivated entries ... that's not really what nowdays code do (without comment i can't imagine the real target of that code in current version) ...

[lvessiller-opendsi]

I'm ok with this fix.
@rycks
Have you something else to add for the error message when you update the dictionary line with "0" as code ?

[eldy]

The protection is here because we want to avoid to have 0 as a code (it generates a lot of trouble).
Here we have a case where legacy code was using 0 as code, so we must fix something to allow this.
However, the fix suggested is a generic fix that allows the 0 as code everywhere, so it breaks the protection everywhere, when it should remove the protection only for the exception case.

[rycks]

@eldy ok, but if the original code was set to zero into sql import from install can user change that value to something else ? that question is to make a good fix.

First idea: if code was zero -> read-only cell & value then it could become a "generic" solution

[eldy]

@eldy ok, but if the original code was set to zero into sql import from install can user change that value to something else ? that question is to make a good fix.

First idea: if code was zero -> read-only cell & value then it could become a "generic" solution

We shoul dnot be able to change for the dictionnary "nature of product".

This property is hard coded at different place in application with some test if (nature == 0) ... or if (nature == 1) then ... so for this dictionnary the value 0 and 1 should not be editable (In the past this was not a dictionnary, dictionary was introduced to allow addition of a third value).
In v20 and v21, it seems this has been fixed by blocking edition of this two lines that are used as hard coded value and only addition of other value is possible.

and i pushed a fix to have the 0 visible as "0"

So i think best fix is to try to retreive same changes done into v20 if we can (if the "always active" is hard coded, in this case no problem to backport, if it uses a new entry in database, in this case we must make a different fix).

[rycks]

@eldy solution backported from 20.0