Openbravo Issue Tracking System - Openbravo ERP
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0030797Openbravo ERPA. Platformpublic2015-09-08 16:492015-09-10 09:37
Reportervmromanos 
Assigned Toalostale 
PrioritynormalSeveritymajorReproducibilityalways
StatusclosedResolutionno change required 
PlatformOS5OS Version
Product Version 
Target Version3.0PR15Q4Fixed in Version 
Merge Request Status
Review Assigned To
OBNetwork customer
Web browser
ModulesCore
Support ticket
Regression level
Regression date
Regression introduced in release
Regression introduced by commit
Triggers an Emergency PackNo
Summary0030797: Validation rule automatically adds wrong organization list to the where clause
DescriptionWhen you define a validation rule it is automatically included in a generic SQL query; the filter by organization and client is automatically set by the system.

Example:

SELECT td0.M_PriceList_Version_ID AS ID, (COALESCE(TO_CHAR(COALESCE(TO_CHAR(td0.Name),'')),'')) AS NAME, '' AS DESCRIPTION
FROM M_PriceList_Version td0
WHERE td0.AD_Client_ID IN ('0','23C59575B9CF467C9620760EB255B389')
AND td0.AD_Org_ID IN ('E443A31992CB4635AFCAEABE7183CE85','B843C30461EA4501935CB1D125C9C25A','19404EAD144C49A0AF37D54377CF452D','0')
AND (<Here the validation rule>) ;


The problem is that the organization list is wrong in the following scenario:

1. A role is defined with User Level = "Organization"
2. In the Role | Organization tab, we define access for Norte and Sur organizations only

In this scenario, the where clause for organizations automatically created for the validation rule is:
AND td0.AD_Org_ID IN ('E443A31992CB4635AFCAEABE7183CE85','B843C30461EA4501935CB1D125C9C25A','19404EAD144C49A0AF37D54377CF452D','0')
which corresponds to Norte (which is the context's organization) and its parents.


This is wrong, as in this concrete case the list should include only Norte and Sur, because it's a role with User Level = Organization and access to Norte and Sur.


Please note that this only happens when the User Level = Organization. If we set it to "Client+Organization", then the where clause properly includes Norte, Sur and *
Steps To ReproduceIn a recent PI instance (with 0030735 fixed)
Login as admin role:

Create a new role:
 Name: rn + rs
 User level: Organization
 Org Access: include only Norte and Sur orgs
 User assignment: Openbravo

Create a price list:
 Name: rn
 Org: Norte
 Sales Price list = Y
 Create a Price List version:
   Name: rn plv

Create a price list:
 Name: rs
 Org: Sur
 Sales Price list = Y
 Create a Price List version:
   Name: rs plv


Log out & log in with Openbravo user
Change the role to rn + rs
Go to Product window:
 Select Agua sin Gas
 Go to Price window:
   Create a new record:
     The only pricelist version is "rn plv". This is wrong, "rn plv" and "rs plv" should be displayed, because they are defined for Norte and Sur and the role has access to them.

Go to Price List window.
Search the "rs" price list
Go to price list version and the Price tab.
Enter a new record. The system allows you. That's OK.


If you now change the role's access level to "Client + Organization", you can select "rn plv" and "rs plv" in Product | Price, Price List Version field

Proposed SolutionIt seems there is something wrong in UIDefinition.java, method getValueInComboReference() when getting the list of organizations to be included in the where clause of the validation rule
Additional Information
TagsNo tags attached.
Relationships
related to design defect 0027459 scheduled reinaldoguerra Data from non-accessible organizations is obtained in Multidimensional reports 
related to defect 0030735 closed AtulOpenbravo All price lists are displayed without check the organization role 
related to defect 00309263.0PR15Q4 closed vmromanos Price list version defined for España organization not available when registering product for * organization 
Attached Files
Issue History
Date ModifiedUsernameFieldChange
2015-09-08 16:49vmromanosNew Issue
2015-09-08 16:49vmromanosAssigned To => platform
2015-09-08 16:49vmromanosModules => Core
2015-09-08 16:49vmromanosTriggers an Emergency Pack => No
2015-09-08 16:52vmromanosRelationship addedrelated to 0030735
2015-09-09 13:35alostaleTarget Version => 3.0PR15Q4
2015-09-09 13:35alostaleStatusnew => scheduled
2015-09-09 13:35alostaleAssigned Toplatform => alostale
2015-09-10 09:11alostaleRelationship addedrelated to 0027459
2015-09-10 09:37alostaleNote Added: 0080308
2015-09-10 09:37alostaleStatusscheduled => closed
2015-09-10 09:37alostaleResolutionopen => no change required
2015-09-25 08:49vmromanosRelationship addedrelated to 0030926

Notes
(0080308)
alostale   
2015-09-10 09:37   
It has nothing to do with validation rule but with organization visibility.

1. Login as sys admin
1.1 Make visible organization field in Price > List tab

2. Login as rn + rs with organization level
2.1 Select Agua sin Gas product
2.2 Create a new price
   -> New record is defaulted to organization Norte
2.3 Open price list version drop down
   -> Only plv n is displayed
2.4 Change org to Sur
2.5 Open price list version drop down
   -> Only plv s is displayed

3. Login as rn + rs with client/organization level
3.1 Select Agua sin Gas product
3.2 Create a new price
   -> New record is defaulted to organization *
3.3 Open price list version drop down
   -> plv n + plv s are displayed
3.4 Change org to Sur
3.5 Open price list version drop down
   -> Only plv s is displayed


Note Agua product is in España organization (which is parent both for Norte and Sur), it can be seen from both roles but none of them has write access there.

When creating a new record in Price tab, it cannot be defaulted to España as it is not writable, so a different writable org is selected (Norte in case of organization level access, * in case of client/org access).

In both cases, elements in price list version are restricted to those ones that can be referred from current record's organization (this is, the natural organization tree: all ancestors and descendants from current org):
* In case 2.2 only Norte can be referred from org Norte
* In cases 2.5 and 3.5 only Sur can be referred from org Sur
* In case 3.3 Norte and Sur can be referred from org *

Note fix for issue 0030735 adds an extra limitation to the price lists that appear in the drop down, filtering out from referable organizations those that current role has not write access to.