Openbravo Issue Tracking System - Openbravo ERP
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0014350Openbravo ERPA. Platformpublic2010-08-27 11:442010-09-13 12:38
Reporternetworkb 
Assigned Toalostale 
PriorityurgentSeveritymajorReproducibilityalways
StatusclosedResolutionsuspended 
PlatformOS20OS VersionCommunity Appliance
Product Version2.50MP20 
Target Version2.50MP22Fixed in Version 
Merge Request Status
Review Assigned To
OBNetwork customerOBPS
Web browser
ModulesCore
Support ticket
Regression level
Regression date
Regression introduced in release
Regression introduced by commit
Triggers an Emergency PackNo
Summary0014350: validation in nested combo does not work
Description. three combos
. combo 2 has got a validation over value of combo 1
. combo 3 has got a validation over value of combo 2
. combo 2 and combo 3 are mandataries.

. when you select a value in combo 1, the values of combo 2 are changed, but the values of combo 3 are not changed
Steps To Reproducein enviroment there are two modules in development mode: normal module and template module
the validation are:
  if the gl category selected is NONE then the project should be Estandar-Estandar.
  if the gl category selected is standard, then the project should be 1000000 - proyecto roma
  if the project selected is Estandar-Estandar, then the currency selected should be AED
  if the project selected is 1000000 - proyecto roma, then the currency selected should be AFA

. Application Dictionary || Setup || Validation Setup || Validation
 . create a new validation:
  name: testProject
  type: sql
  validation: ((@GL_CATEGORY_ID@='0' AND C_PROJECT_ID = '1000000') OR (@GL_CATEGORY_ID@='1000000' AND C_PROJECT_ID = '1000001'))

 . create a new validation:
  name: test currency
  type: sql
  validation: ((@C_PROJECT_ID@='1000000' AND C_CURRENCY_ID ='238') OR (@C_PROJECT_ID@='1000001' AND C_CURRENCY_ID ='195'))

. Application Dictionary || Tables and Columns || Table
 select GL_JOURNAL

. Application Dictionary || Tables and Columns || Table >> Column
 select column project
   check mandatary
   select validation testProject

 select column currency
   select validation test currency

. run "ant smartbuild"

. access to application to window
. Financial Management || Accounting || Transactions || G/L Journal || Batch
 create a new record
. Financial Management || Accounting || Transactions || G/L Journal || Batch >> Header
 create a new record
  select gl category: NONE
  automatically, the project selected is Estandar-Estandar, it is Ok
  but the currency selected is not AED

  select gl category: standard
  automatically, the project selected is 1000000 - Proyecto Roma
  but the currency selected is not AFA
Proposed Solution
Additional Information
TagsNo tags attached.
Relationships
Attached Files
Issue History
Date ModifiedUsernameFieldChange
2010-08-27 11:44networkbNew Issue
2010-08-27 11:44networkbAssigned To => alostale
2010-08-27 11:44networkbOBNetwork customer => Yes
2010-08-30 08:54alostaleStatusnew => scheduled
2010-08-30 08:54alostalefix_in_branch => pi
2010-08-30 13:06alostaleNote Added: 0030454
2010-08-31 08:29alostaleNote Edited: 0030454bug_revision_view_page.php?bugnote_id=0030454#r766
2010-08-31 08:31alostaleNote Added: 0030496
2010-08-31 08:31alostaleStatusscheduled => closed
2010-08-31 08:31alostaleResolutionopen => suspended
2010-09-13 12:38anonymoussf_bug_id0 => 3065189

Notes
(0030454)
alostale   
2010-08-30 13:06   
(edited on: 2010-08-31 08:29)
The technical root cause for this issue is:

1. When a field is modified associated callouts are fired.
2. Callouts are executed in cascade, so if callout in field A, modifies field B, callout for field B is executed.
3. In case the same callout executed for A is called for B, it is not executed to prevent cycles.
4. The problem is all validations for the same tab are implemented by a single callout (combo reload), so the second time it is not fired.

A possible solution could be to perform all the cascade logic in the back end so the combo reload would be executed once populating all the changes.
(0030496)
alostale   
2010-08-31 08:31   
This issue is not going to be fixed because of the risk of the change that would affect a very core feature which could cause unexpected regressions.

The workaround is to implement these two validations manually in a callout.