Openbravo Issue Tracking System - Openbravo ERP
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0025678Openbravo ERPB. User interfacepublic2014-02-06 16:352014-03-27 14:05
Reporterchelipf 
Assigned ToAugustoMauch 
PrioritynormalSeverityminorReproducibilityalways
StatusclosedResolutionno change required 
PlatformOS30OS VersionDebian Wheezy
Product Version3.0MP31 
Target Version3.0PR14Q2Fixed in Version 
Merge Request Status
Review Assigned To
OBNetwork customer
Web browserMozilla Firefox
ModulesCore
Support ticket
Regression level
Regression date
Regression introduced in release
Regression introduced by commit
Triggers an Emergency PackNo
Summary0025678: When creating a new line, @variable@ of a combo is set with the old default value.
DescriptionFor example, you have in a tab a column ad_user_id as a table reference (references to AD_USER table) and the default value (as a result of the select sentence that fills the combo) when the combo is painted in the user interface is Cheli (ad_user_id = '525AF15DEFF14C948C396D4718A7A8A3'). If a create a new line in my tab then the @AD_User_ID@ is set to '525AF15DEFF14C948C396D4718A7A8A3' when it should be null because it is a "new" line without any value in that moment.
Steps To Reproduce-Create a new line in any tab, that tab must contain a combo box (tabledir, table, etc) and should be a mandatory field. The @variable@ then is set with the value it is filled in.
-Create another line. The @variable@ value by default will be set with the old @variable@ one.
- If you log out and log in again @variable@ is set to null by default. After the first insert it is set again with the old @variable@ value every time yo insert a new line.
Proposed SolutionEvery time you create a new line all the @variable@ values must be set to null by default.
Additional Information
TagsSidesoft
Relationships
related to feature request 0025762 new AugustoMauch To be able to set a table /tabledir columns as unique relative to its master tab if exists. 
related to feature request 0026111 new AugustoMauch Add a flag at column level to avoid the load of the value stored in session in the initial value of the variable 
Attached Files
Issue History
Date ModifiedUsernameFieldChange
2014-02-06 16:35chelipfNew Issue
2014-02-06 16:35chelipfAssigned To => dbaz
2014-02-06 16:35chelipfWeb browser => Mozilla Firefox
2014-02-06 16:35chelipfModules => Core
2014-02-06 16:35chelipfTriggers an Emergency Pack => No
2014-02-10 23:07chelipfTag Attached: Sidesoft
2014-02-19 18:09jonalegriaesarteWeb browserMozilla Firefox => Mozilla Firefox
2014-02-19 18:09jonalegriaesarteTarget Version => 3.0MP32
2014-02-19 18:09jonalegriaesarteAssigned Todbaz => AugustoMauch
2014-03-11 13:19jonalegriaesarteWeb browserMozilla Firefox => Mozilla Firefox
2014-03-11 13:19jonalegriaesarteResolution time => 1394838000
2014-03-12 11:23alostaleNote Added: 0065093
2014-03-18 11:26AugustoMauchStatusnew => scheduled
2014-03-18 11:26AugustoMauchfix_in_branch => pi
2014-03-18 17:44chelipfNote Added: 0065272
2014-03-18 21:10AugustoMauchNote Added: 0065278
2014-03-18 21:10AugustoMauchStatusscheduled => feedback
2014-03-19 00:03chelipfNote Added: 0065282
2014-03-27 14:04jonalegriaesarteRelationship addedrelated to 0025762
2014-03-27 14:05jonalegriaesarteStatusfeedback => closed
2014-03-27 14:05jonalegriaesarteResolutionopen => no change required
2014-03-27 14:08jonalegriaesarteRelationship addedrelated to 0026111

Notes
(0065093)
alostale   
2014-03-12 11:23   
Adding more info:
- Tenemos una solapa con un campo propio, por ejemplo usuario.
- La primera vez que accedemos a la ventana, el valor de la variable usuario
@PREFIX_AD_USER_ID@ es nulo
- Guardamos el valor X
- Le damos a nuevo, el valor de la variable @PREFIX_AD_USER_ID@ es X, en vez de ser nulo.
Es decir, es como si la segunda y siguientes veces, el valor por defecto de la variable @PREFIX_AD_USER_ID@ fuera el último valor guardado. Esto hace que dé problemas al utilizar el campo @PREFIX_AD_USER_ID@ en validaciones, auxiliar inputs...
(0065272)
chelipf   
2014-03-18 17:44   
This is the validation rule I use:

sfb_budget_area_id not in (select sfb_budget_area_id from sfb_budget_user_area where ad_user_id = @AD_User_ID@ and sfb_budget_area_id is not null and (sfb_budget_area_id <> @Sfb_Budget_Area_ID@ or @Sfb_Budget_Area_ID@ IS NULL))
(0065278)
AugustoMauch   
2014-03-18 21:10   
After discussing it with the reporter, it seems that the problem is that the flag 'Store in Session' is checked for the column whose value is being initialized from the last value used for that column. This is the expected behaviour for Stored in Session columns.

The reporter is going to check if it is possible to unset this flag, and to see if in that case the problem is no longer reproducible.
(0065282)
chelipf   
2014-03-19 00:03   
I have checked it and it works as you expect when the variable is not set as stored in session, but the problem persists when it is.

I still think that even when it is stored in session the variable must be set with the default field value, null or anything the default value could be, when creating a new line (pristine) and the form is loaded for the first time, instead of still be set with the old stored in session one. It is supposed that the default value of that variable when you start to fill out the form is null or the default one you define in the application dictionary. As we have talk this evening it could be a new feature for next releases.

Thank you Augusto.