Anonymous | Login
Project:
RSS
  
News | My View | View Issues | Roadmap | Summary

View Issue Details[ Jump to Notes ] [ Issue History ] [ Print ]
ID
0036598
TypeCategorySeverityReproducibilityDate SubmittedLast Update
defect[Openbravo ERP] A. Platformmajoralways2017-08-04 09:352017-09-21 16:49
ReportervmromanosView Statuspublic 
Assigned Toinigosanchez 
PriorityurgentResolutionfixedFixed in Version3.0PR17Q4
StatusclosedFix in branchFixed in SCM revision74017a22fc13
ProjectionnoneETAnoneTarget Version3.0PR17Q4
OSAnyDatabaseAnyJava version
OS VersionDatabase versionAnt version
Product VersionSCM revision 
Review Assigned Tocaristu
Web browser
ModulesCore
Regression level
Regression date
Regression introduced in release
Regression introduced by commit
Triggers an Emergency PackNo
Summary

0036598: Process Definition for multirecord sets only one organization in filter parameters

DescriptionA Process Definition is defined to work with multirecords. In this case you can select records belonging to different organizations.
However, when the records are submitted to the server, a unique parameter "_org=" is sent as filter. Then the server detects it and tries to get the natural tree for this organization.
When you have selected records belonging to different trees, the records belonging to a different natural tree of the "_org" parameter are filtered out.
Steps To ReproduceCreate a Process Definition for multirecord and standard ui.
Add a grid that shows Sales Invoices
Create a button in Sales Invoice window and link it to the process definition

In the onload function for the Process Definition add a similar code, replacing the necessary lines (mainly function name and grid name):

OB.OBAWO.onLoad = function (view) {
  var selection, paramGrid, parentGrid, criteria, gridCriteria;

  parentGrid = view.parentWindow.view.viewGrid;
  selection = parentGrid.getSelectedRecords();
  paramGrid = view.theForm.getItem('stock').canvas.viewGrid;

  criteria = [];
  selection.forEach(function (r) {
    criteria.push({
      fieldName: 'id',
      operator: 'equals',
      value: r.id
    });
  });
  gridCriteria = {
          operator: 'or',
    _constructor: 'AdvancedCriteria',
    criteria: criteria
  };

  paramGrid.dataSource.requestProperties.params.criteria = gridCriteria;
  
};


The idea is to select some records in Sales Invoice window, press the Process Definition button, and display only those records in the new popup grid.


In Sales Invoice window select 2 records, one for Norte and the other for Sur. Press the Process Definition button.
Verify just one record is shown.
Close the popup.

Repeat the selection, but this time selecting several records from the same org.
Verify all the records are now shown in the new grid.



Set a break point in AdvancedQueryBuilder.java, addWhereOrgParameters method.
And repeat the process.
Verify filterparameters contains a parameter _org with any of the organizations, that is used to add the natural tree filter. Example (in my case I work with storage details):

{@MaterialMgmtStorageDetail.storageBin@=4B413455BCE541C0AB80E18BFD7247B5, @MaterialMgmtStorageDetail.client@=A64C68776B544B0DB59C16456C43E608, @MaterialMgmtStorageDetail.product@=110D54D3A4214D3095008EC8F35D88B5, @MaterialMgmtStorageDetail.id@=DBB2E952074E47A5B4377B4115F03F02, whereAndFilterClause=e.qtyPutAway>0, @MaterialMgmtStorageDetail.organization@=3FF21930C89F4A8FAC60E7264BF96568, @MaterialMgmtStorageDetail.uOM@=100, _org=3FF21930C89F4A8FAC60E7264BF96568, @MaterialMgmtStorageDetail.attributeSetValue@=0}
Proposed SolutionWhen selecting multiple records, it would be better to set the JsonConstants.CALCULATE_ORGS parameter instead so we enter by the second if:

    if (filterParameters.containsKey(JsonConstants.ORG_PARAMETER)) {
      final String value = filterParameters.get(JsonConstants.ORG_PARAMETER);
      if (entity.isOrganizationEnabled() && value != null && value.length() > 0) {
        orgs = OBContext.getOBContext().getOrganizationStructureProvider().getNaturalTree(value);
        orgPart = buildOrgPartWhereClause(orgs);
      }
      localWhereClause = buildLocalWhereClause(localWhereClause, orgPart);
    } else if (filterParameters.containsKey(JsonConstants.CALCULATE_ORGS)) {
      // add natural tree of writable organizations
      final Set<String> orgsWritables = OBContext.getOBContext().getWritableOrganizations();
      for (final String o : orgsWritables) {
        orgs.addAll(OBContext.getOBContext().getOrganizationStructureProvider().getNaturalTree(o));
      }
      orgPart = buildOrgPartWhereClause(orgs);
      localWhereClause = buildLocalWhereClause(localWhereClause, orgPart);
    }
TagsNo tags attached.
Attached Files

- Relationships [ Relation Graph ] [ Dependency Graph ]
related to defect 0036151 closedcaristu organization selector in process definition don't filter by role's org access 
related to defect 0035124 closedinigosanchez Selectors in Process Definition invoked from menu show only records of organizations in the context organization's natural tree 

-  Notes
(0098749)
hgbot (developer)
2017-08-31 11:24

 Repository: erp/devel/pi
Changeset: 74017a22fc13565b4f2988a87fffc17fae151cf6
Author: Inigo Sanchez <inigo.sanchez <at> openbravo.com>
Date: Thu Aug 31 11:22:01 2017 +0200
URL: http://code.openbravo.com/erp/devel/pi/rev/74017a22fc13565b4f2988a87fffc17fae151cf6 [^]

Fixed issue 36598: Multirecord Process sets only one organization in parameters

A standard process can be defined as multi record process to be able to execute it for more than one
record. In this case it can be selected records belonging to different organizations. The reported
problem was that in this situation it was take into account only the first organization sending it
as "_org" parameter.


This problem has been fixed by managing this situation properly. Now, when a multirecord process is
launched and more than one record is selected, the natural tree of writable organizations of the
current context is calculated instead of the natural tree of the first organization of the first
selected record.

---
M modules/org.openbravo.client.application/web/org.openbravo.client.application/js/process/ob-pick-and-execute-grid.js
---
(0098768)
alostale (manager)
2017-09-01 09:09

 Working correctly for grids shown in P&E, but to be consistent the same behavior should also apply to selector fields in P&E. Note this is already implemented when the process is opened from menu.

Steps:

1. Add a BP selector to created P&E
2. Select a single record and open the process
   -> OK: grid shows only records in the same org tree as the selected record
   -> OK: BP selector filters only those BPs in the same org tree as selected record
3. Select multiple records and open the process
   -> OK: grid shows records in the tree of all orgs current role has access to
   -> FAIL: BP selector filters records in the org tree of the last selected record, would expect to apply same criteria than grid
(0098792)
hgbot (developer)
2017-09-04 10:01

 Repository: erp/devel/pi
Changeset: 1e69815c84cb4dc56743b7d5ee4837ae237b7258
Author: Inigo Sanchez <inigo.sanchez <at> openbravo.com>
Date: Fri Sep 01 14:15:27 2017 +0200
URL: http://code.openbravo.com/erp/devel/pi/rev/1e69815c84cb4dc56743b7d5ee4837ae237b7258 [^]

Related with the issue 36598: now selectors are working as expected in P&E

Selecting multiple records and opening the process with a selector in the 'P&E' it is
failing.

The problem has been fixed by take into account this case. Now when the selector is open
shows records in the tree of all orgs current role has access instead of records in the
org tree of the last selected record.

---
M modules/org.openbravo.userinterface.selector/web/org.openbravo.userinterface.selector/js/ob-selector-item.js
---
(0099103)
caristu (developer)
2017-09-18 12:20

 Code reviewed + tested OK.
(0099350)
hudsonbot (developer)
2017-09-21 16:49

 A changeset related to this issue has been promoted main and to the
Central Repository, after passing a series of tests.

Promotion changeset: https://code.openbravo.com/erp/devel/main/rev/9750b78d3e5c [^]
Maturity status: Test
(0099353)
hudsonbot (developer)
2017-09-21 16:49

 A changeset related to this issue has been promoted main and to the
Central Repository, after passing a series of tests.

Promotion changeset: https://code.openbravo.com/erp/devel/main/rev/9750b78d3e5c [^]
Maturity status: Test

- Issue History
Date Modified Username Field Change
2017-08-04 09:35 vmromanos New Issue
2017-08-04 09:35 vmromanos Assigned To => platform
2017-08-04 09:35 vmromanos Modules => Core
2017-08-04 09:35 vmromanos Triggers an Emergency Pack => No
2017-08-04 09:36 vmromanos Steps to Reproduce Updated View Revisions
2017-08-04 09:36 vmromanos Proposed Solution updated
2017-08-04 09:46 alostale Priority high => urgent
2017-08-04 09:46 alostale Status new => acknowledged
2017-08-10 10:21 alostale Relationship added related to 0036151
2017-08-18 13:56 inigosanchez Assigned To platform => inigosanchez
2017-08-18 13:56 inigosanchez Status acknowledged => scheduled
2017-08-18 13:56 inigosanchez Status scheduled => feedback
2017-08-24 13:46 inigosanchez Status feedback => scheduled
2017-08-30 12:50 inigosanchez Relationship added related to 0035124
2017-08-31 11:24 hgbot Checkin
2017-08-31 11:24 hgbot Note Added: 0098749
2017-08-31 11:24 hgbot Status scheduled => resolved
2017-08-31 11:24 hgbot Resolution open => fixed
2017-08-31 11:24 hgbot Fixed in SCM revision => http://code.openbravo.com/erp/devel/pi/rev/74017a22fc13565b4f2988a87fffc17fae151cf6 [^]
2017-08-31 11:26 inigosanchez Review Assigned To => alostale
2017-09-01 09:09 alostale Note Added: 0098768
2017-09-01 09:09 alostale Status resolved => new
2017-09-01 09:09 alostale Resolution fixed => open
2017-09-01 10:27 inigosanchez Status new => scheduled
2017-09-04 10:01 hgbot Checkin
2017-09-04 10:01 hgbot Note Added: 0098792
2017-09-04 10:02 inigosanchez Status scheduled => resolved
2017-09-04 10:02 inigosanchez Fixed in Version => 3.0PR17Q4
2017-09-04 10:02 inigosanchez Resolution open => fixed
2017-09-11 17:13 caristu Review Assigned To alostale => caristu
2017-09-18 12:20 caristu Note Added: 0099103
2017-09-18 12:20 caristu Status resolved => closed
2017-09-21 16:49 hudsonbot Checkin
2017-09-21 16:49 hudsonbot Note Added: 0099350
2017-09-21 16:49 hudsonbot Checkin
2017-09-21 16:49 hudsonbot Note Added: 0099353

Copyright © 2000 - 2009 MantisBT Group
Powered by Mantis Bugtracker