IDempiere/FullMeeting20150617 - Revision history

CarlosRuiz: drop JIRA notifications from log

2015-06-17T23:28:54Z

drop JIRA notifications from log

CarlosRuiz: full meeting

2015-06-17T23:28:06Z

full meeting

New page

⇐
[[IDempiere|Table of Contents]] |
[[IDempiere/Full Meeting Minutes|Full Meeting Minutes]] |
Full Meeting 2015-06-17


'''''CarlosRuiz''''': Good Morning 
'''''nmicoud''''': Bonjour 
'''''druiz''''': Hola 
'''''nmicoud''''': CarlosRuiz, could you have a look at those 2 little patches (2685, 2678 ) and then at 2679 (which will take more time - and still as draft) ? 
'''''CarlosRuiz''''': ok 
'''''nmicoud''''': thanks 
'''''Not-604a''''': [iDempiere] CarlosRuiz_globalqss pushed 1 commit to release-2.1 [+2/-0/±0] https://bitbucket.org/idempiere/idempiere/commits/ 
'''''Not-604a''''': [iDempiere] nmicoud 5364b7b - IDEMPIERE-2685 Jasper process field should be visible only for Advanced roles 
'''''Not-604a''''': [IDEMPIERE] carlosruiz_globalqss updated IDEMPIERE-2685 status set to "Resolved" -assignee set to "Nicolas Micoud" -resolution set to "Fixed" 
'''''Not-604a''''': [IDEMPIERE] http://idempiere.atlassian.net/browse/IDEMPIERE-2685 
'''''CarlosRuiz''''': nmicoud, 
'''''CarlosRuiz''''': testing 2678 on Test Window (r2.1) 
'''''CarlosRuiz''''': I set null as default value for Integer, Number, Amount and Qty 
'''''CarlosRuiz''''': when saving just integer was saved as null 
'''''CarlosRuiz''''': number, amount and qty were saved as zero 
'''''nmicoud''''': let me check 
'''''nmicoud''''': at first, i wanted to add something like if Amount and DefaultLogic.equals("NULL") 
'''''nmicoud''''': but it was maybe more useful to apply this patch to all field 
'''''nmicoud''''': Did you syncrhonize the column ? 
'''''nmicoud''''': i mean, there is no default value in the db 
'''''CarlosRuiz''''': ah - let me check - I tested setting the default on window 
'''''Deepak__''''': Good Morning all 
'''''tbayen''''': Daarestiet :-) 
'''''CarlosRuiz''''': hi Deepak__ - hi tbayen 
'''''nmicoud''''': is ok here with NULL in column + synchronize column 
'''''nmicoud''''': (oracle) 
'''''CarlosRuiz''''': good nmicoud - it worked the db default was wrongly set 
'''''nmicoud''''': but it means that this kind of default cannot be set in the field, right ? 
'''''nmicoud''''': it has to be set in the column 
'''''CarlosRuiz''''': yes - it can 
'''''nmicoud''''': or at least, the column in db must have null as default 
'''''CarlosRuiz''''': just that the column in the db was not corresponding to the column in ad_column 
'''''CarlosRuiz''''': I just synchronized - and the default was changed from 0 to null - without touching ad_column 
'''''nmicoud''''': ok 
'''''Not-604a''''': [iDempiere] CarlosRuiz_globalqss pushed 1 commit to release-2.1 [+0/-0/±1] https://bitbucket.org/idempiere/idempiere/commits/ 
'''''Not-604a''''': [iDempiere] nmicoud aa2906f - IDEMPIERE-2678 Allow to set explicit NULL value for fields 
'''''Not-604a''''': [IDEMPIERE] carlosruiz_globalqss updated IDEMPIERE-2678 status set to "Resolved" -assignee set to "Nicolas Micoud" -resolution set to "Fixed" 
'''''Not-604a''''': [IDEMPIERE] http://idempiere.atlassian.net/browse/IDEMPIERE-2678 
'''''aguerra''''': hi everybody 
'''''aguerra''''': good morning!!! 
'''''Not-604a''''': [iDempiere2.1] jenkins built #234 completed (success) http://ci.idempiere.org/job/iDempiere2.1/234/ 
'''''CarlosRuiz''''': Hi aguerra 
'''''Not-604a''''': [iDempiere2.1] jenkins built #235 completed (success) http://ci.idempiere.org/job/iDempiere2.1/235/ 
'''''druiz''''': @CarlosRuiz have you had time to check IDEMPIERE-2673 
'''''CarlosRuiz''''': not yet - will check it today 
'''''mhernandezve''''': hello idempierans! ;) 
'''''CarlosRuiz''''': Hi mhernandezve 
'''''aguerra''''': hi mhernandezve 
'''''lescano''''': @CarlosRuiz, ref. https://idempiere.atlassian.net/browse/IDEMPIERE-2676 seems not to have a easy resolution 
'''''CarlosRuiz''''': I haven't checked, it sounds like a callout is reading info from another window 
'''''lescano''''': actually, it is related to context variables in a window. After a query for another record, some variables remains instead of clearing 
'''''lescano''''': query seems to be broken 
'''''norbertbede''''': hi all 
'''''lescano''''': hi norbert 
'''''norbertbede''''': people interested in replication should help me answer a tricky question well :) 
'''''norbertbede''''': https://groups.google.com/forum/#!topic/idempiere/3v4ipKmhoE8 
'''''CarlosRuiz''''': hi norbertbede 
'''''Deepak''''': Hello Norbert, I just responded to you group message 
'''''Deepak''''': hope that helps 
'''''norbertbede''''': ah i see 
'''''norbertbede''''': thanks going to check 
'''''Not-604a''''': [IDEMPIERE] norbert.bede updated IDEMPIERE-2660 description set to "we found the following process could be improved well: *Product Category filter (parameter 1)* ------------------------------ _{color:#707070}by product category filter users are able to filter specific lines from orders by his product cagetory - where shipment and invoice rules are fit and not yet invoiced. Important: parent/child categories must be 
'''''Not-604a''''': considered. well{color}_ example use case: user wants to invoice first: foods then office equipments. *Split orderlines by (parameter 2)* ------------------------------ _{color:#707070}by this parameter users are able to split invoices - to be created - by given option - then - where shipment and invoice rules are fit and not yet invoiced{color}_ ** split by salesman - invoice per order customers ** split by orders 
'''''Not-604a''''': ** split by order reference ** split by shipments ** split by location(departments) - example use case: multiple invoices created for business partner - split by locations. e.g 100 shipments 10 invoice in period *Lines Order by (parameter 3)* --------------------------------------------- _{color:#707070}by this parameter users are able to define how lines - generated to invoice will be ordered - to be created - by 
'''''Not-604a''''': given option - then - where shipment and invoice rules are fit and not yet invoiced{color}_ ** no grouping ** group by orders ** group by address ** group by shipments *Generate Notes (parameter 3)* --------------------------------------------- actual behaviour is: Shipment: TR/DL/150612089 (docno) - 18/06/2015 (date) yes/no Note 1. other ideas required - for better design Note 2. other ideas in code review required 
'''''Not-604a''''': - for better design Note 3. parameter 2 and 3 are - could be in conflict - ideas are welcome. " 
'''''Not-604a''''': [IDEMPIERE] http://idempiere.atlassian.net/browse/IDEMPIERE-2660 
'''''Not-604a''''': [iDempiere] CarlosRuiz_globalqss pushed 1 commit to release-2.1 [+0/-0/±6] https://bitbucket.org/idempiere/idempiere/commits/ 
'''''Not-604a''''': [iDempiere] globalqss 2fcb262 - IDEMPIERE-2664 DB Extensibility issues / calling convert for direct prepareStatement 
'''''Not-604a''''': [iDempiere2.1] jenkins built #236 completed (success) http://ci.idempiere.org/job/iDempiere2.1/236/ 
'''''norbertbede''''': CarlosRuiz where is or hieplq. 
'''''norbertbede''''': he being silent latest weeks :) 
'''''CarlosRuiz''''': yes, some time without hearing from him 
'''''CarlosRuiz''''': lescano, still there? 
'''''lescano''''': yes 
'''''CarlosRuiz''''': the solution I see is to avoid setting M_PriceList_Version_ID in the context - there is a query in CalloutOrder and CalloutInvoice to check the price list version when is not in the context - and then it sets it 
'''''CarlosRuiz''''': if we simply never set it - then it must work 
'''''lescano''''': I temporally solved here doing this, but this way we are ignoring a lot of future problems not related to pricelists 
'''''lescano''''': there are similar problems with other variables 
'''''CarlosRuiz''''': ah I see - your comment points to clear any other potential dangerous field 
'''''CarlosRuiz''''': your comment to call clearWinContext 
'''''lescano''''': yes. I've tried changing this in GridTab.query() (after testing if TabNo==0) but cleaned also important variables that shouldn't be cleaned 
'''''CarlosRuiz''''': even that way I see that InfoProduct is setting price list version - there must be another issue there 
'''''CarlosRuiz''''': testing - info product seems ok 
'''''CarlosRuiz''''': I guess you must not clear _TabInfo_ and _WinInfo_ ctx - right? 
'''''lescano''''': so many callouts set context variables, and seems hard to handle them over GridTab queries. Maybe the solution would clean plus reset (similar when opening new GridTab) when querying 
'''''CarlosRuiz''''': lescano - not just when querying - must be happening also when navigating to a different record with a different price list 
'''''lescano''''': hmm, isn't GridTab.query() always called when navigating and changing tab? 
'''''CarlosRuiz''''': I checked and it seems is GridTab.setCurrentRow 
'''''CarlosRuiz''''': I'm uploading a possible patch 
'''''Not-604a''''': [IDEMPIERE] carlosruiz_globalqss updated IDEMPIERE-2676 Attachment set to "IDEMPIERE-2676_v0.patch" 
'''''Not-604a''''': [IDEMPIERE] [~alan.lesc1], I'm uploading a possible patch following your suggestion and what we talked on IRC meeting. Can you please test it and provide feedback? 
'''''Not-604a''''': [IDEMPIERE] http://idempiere.atlassian.net/browse/IDEMPIERE-2676 
'''''lescano''''': @CarlosRuiz thank you, I will test right now 
'''''lescano''''': CarlosRuiz, it doesn't work properly because setCurrentRow() is called by dataDelete(), dataRefresh(), etc... and context variables are cleared when they shouldn't be 
'''''CarlosRuiz''''': lescano, why? 
'''''CarlosRuiz''''': whenever you navigate to a new record - the context variables set for the old record are obsolete - and dangerous as in the case you found 
'''''lescano''''': I agree, but the patch is removing variables when, for example, saving order line 
'''''lescano''''': this may broke current funcionality 
'''''CarlosRuiz''''': ah yes - I see 
'''''CarlosRuiz''''': changed the if on GridTab to this one: 
'''''CarlosRuiz''''': if (m_vo.TabLevel == 0 && m_currentRow != newCurrentRow) 
'''''CarlosRuiz''''': seems it works better 
'''''CarlosRuiz''''': ah - found another ctx variable Base_Table_ID - must start with _WinInfo_ better 
'''''CarlosRuiz''''': BaseTable_ID - very easy to collide with a real column 
'''''lescano''''': you're right 
'''''lescano''''': seems to work now. I'll do more tests and compare if any variable is being wrongly removed using the patch 
'''''CarlosRuiz''''': I think the ctx for IsSOTrx must be preserved also 
'''''lescano''''': hmm, for tables like c_payment this may be a problem 
'''''lescano''''': because both PO and SO records use same window Payment 
'''''CarlosRuiz''''': I see two more window properties -> AutoCommit and AutoNew 
'''''CarlosRuiz''''': maybe this is not right approach :-( 
'''''CarlosRuiz''''': could break other things that people trusted to put in context on plugins 
'''''lescano''''': Initially, the best solution seems to clear the context for window ... but thinking better, it really may break third-party codes 
'''''CarlosRuiz''''': another approach is to fix the CalloutOrder and CalloutInvoice to not read the price list version from context 
'''''CarlosRuiz''''': and thinking on a possible third approach could be to call the CalloutOrder.priceList when navigating 
'''''lescano''''': I should go now, but I'll try to think another aproach 
'''''CarlosRuiz''''': that's not possible actually - but I've always thought could be a good addition to allow callouts on navigation 
'''''lescano''''': yes, but... 
'''''lescano''''': I see a problem with other variables 
'''''CarlosRuiz''''': yep EnforcePriceLimit for example - which is set on CalloutOrder.pricelist 
'''''Not-604a''''': [IDEMPIERE] carlosruiz_globalqss updated IDEMPIERE-2676 Attachment set to "IDEMPIERE-2676_v1.patch" 
'''''Not-604a''''': [IDEMPIERE] Just for documentation of this process, a second patch checking for more variables - talking with [~alan.lesc1] on IRC seems like this is not the best approach 
'''''Not-604a''''': [IDEMPIERE] http://idempiere.atlassian.net/browse/IDEMPIERE-2676 
'''''Not-604a''''': [IDEMPIERE] carlosruiz_globalqss updated IDEMPIERE-2676 Attachment set to "IDEMPIERE-2676_v2_fixingCallouts.patch" 
'''''Not-604a''''': [IDEMPIERE] Another approach discussed is in patch IDEMPIERE-2676_v2_fixingCallouts.patch Fixing the callouts to avoid the context variable and always look for the price list version. 
'''''Not-604a''''': [IDEMPIERE] http://idempiere.atlassian.net/browse/IDEMPIERE-2676 
'''''lescano''''': seems to solve pricelist issue. And we try to solve other context variables issues as they come in. 
'''''Not-604a''''': [iDempiere] CarlosRuiz_globalqss pushed 1 commit to release-2.1 [+0/-0/±1] https://bitbucket.org/idempiere/idempiere/commits/ 
'''''Not-604a''''': [iDempiere] globalqss 5a17930 - IDEMPIERE-2664 DB Extensibility issues 
'''''lescano''''': Anyway , I'll keep thinking of another way to solve the context variables issue. Thank you very much Carlos, have a nice end of day 
'''''CarlosRuiz''''': thanks to you Alan 
'''''Not-604a''''': [iDempiere2.1] jenkins built #237 completed (success) http://ci.idempiere.org/job/iDempiere2.1/237/ 
'''''Not-604a''''': [IDEMPIERE] carlosruiz_globalqss updated IDEMPIERE-2676 Attachment set to "None" 
'''''Not-604a''''': [IDEMPIERE] http://idempiere.atlassian.net/browse/IDEMPIERE-2676 
'''''Not-604a''''': [IDEMPIERE] carlosruiz_globalqss updated IDEMPIERE-2676 Attachment set to "IDEMPIERE-2676_v1.patch" 
'''''Not-604a''''': [IDEMPIERE] http://idempiere.atlassian.net/browse/IDEMPIERE-2676 
'''''Not-604a''''': [IDEMPIERE] carlosruiz_globalqss updated IDEMPIERE-2676 Attachment set to "IDEMPIERE-2676_v3_CalloutOnNavigate.patch" 
'''''Not-604a''''': [IDEMPIERE] Another approach is to implement the ability to execute a callout when navigating to a new record - this is a very wanted feature that can serve for many other purposes - mostly setting or clearing context whenever you navigate to a new record. Tested the patch IDEMPIERE-2676_v3_CalloutOnNavigate.patch with this approach and it seems to work fine. 
'''''Not-604a''''': [IDEMPIERE] http://idempiere.atlassian.net/browse/IDEMPIERE-2676 
'''''Not-604a''''': [IDEMPIERE] carlosruiz_globalqss updated IDEMPIERE-2676 labels set to "+Patch" 
'''''Not-604a''''': [IDEMPIERE] http://idempiere.atlassian.net/browse/IDEMPIERE-2676 
'''''junooni''''': is there any user of adempiere from UAE 
'''''Not-604a''''': [IDEMPIERE] carlosruiz_globalqss updated IDEMPIERE-2684 
'''''Not-604a''''': [IDEMPIERE] Hi, tested this issue found that maybe is not needed - you just need to implement your own ProcessFactory and return your own custom ReportStarter. Just like the org.adempiere.report.jasper.ProcessFactory is returning the ReportStarter if the class is set like org.adempiere.report.jasper.ReportStarter or org.compiere.report.ReportStarter. Can you please check on your plugin if that approach works? Your 
'''''Not-604a''''': process factory requires also a service.ranking to be taken into account before the default which has service.ranking=1 
'''''Not-604a''''': [IDEMPIERE] http://idempiere.atlassian.net/browse/IDEMPIERE-2684 
'''''Not-604a''''': [iDempiere] CarlosRuiz_globalqss pushed 1 commit to release-2.1 [+0/-0/±1] https://bitbucket.org/idempiere/idempiere/commits/ 
'''''Not-604a''''': [iDempiere] globalqss 698e7e1 - IDEMPIERE-2673 Custom status line message not updating in different records 
'''''Not-604a''''': [IDEMPIERE] carlosruiz_globalqss updated IDEMPIERE-2673 status set to "Resolved" -assignee set to "Carlos Antonio Ruiz Gomez" -resolution set to "Fixed" 
'''''Not-604a''''': [IDEMPIERE] Committed a different patch - for your test case on demo is better to use LEFT JOIN on C_OrderLine and M_Product so it can show information for orders without lines. 
'''''Not-604a''''': [IDEMPIERE] http://idempiere.atlassian.net/browse/IDEMPIERE-2673 
'''''Not-604a''''': [iDempiere] CarlosRuiz_globalqss pushed 1 commit to development [+2/-0/±8] https://bitbucket.org/idempiere/idempiere/commits/ 
'''''Not-604a''''': [iDempiere] globalqss aaf6911 - hg merge release-2.1 (merge release2.1 into development)

@@ Line 13: / Line 13: @@
 '''''CarlosRuiz''''': ok<br>
 '''''nmicoud''''': thanks<br>
 '''''CarlosRuiz''''': nmicoud, <br>
 '''''CarlosRuiz''''': testing 2678 on Test Window (r2.1)<br>
@@ Line 41: / Line 37: @@
 '''''CarlosRuiz''''': I just synchronized - and the default was changed from 0 to null - without touching ad_column<br>
 '''''nmicoud''''': ok<br>
 '''''aguerra''''': hi everybody<br>
 '''''aguerra''''': good morning!!!<br>
 '''''CarlosRuiz''''': Hi aguerra <br>
 '''''druiz''''': @CarlosRuiz have you had time to check IDEMPIERE-2673<br>
 '''''CarlosRuiz''''': not yet - will check it today<br>
@@ Line 68: / Line 58: @@
 '''''norbertbede''''': ah i see<br>
 '''''norbertbede''''': thanks going to check<br>
 '''''norbertbede''''': CarlosRuiz where is or hieplq.<br>
 '''''norbertbede''''': he being silent latest weeks :)<br>
@@ Line 97: / Line 78: @@
 '''''CarlosRuiz''''': I checked and it seems is GridTab.setCurrentRow<br>
 '''''CarlosRuiz''''': I'm uploading a possible patch<br>
 '''''lescano''''': @CarlosRuiz thank you, I will test right now<br>
 '''''lescano''''': CarlosRuiz, it doesn't work properly because setCurrentRow() is called by dataDelete(), dataRefresh(), etc... and context variables are cleared when they shouldn't be<br>
@@ Line 128: / Line 106: @@
 '''''lescano''''': I see a problem with other variables<br>
 '''''CarlosRuiz''''': yep EnforcePriceLimit for example - which is set on CalloutOrder.pricelist<br>
 '''''lescano''''': seems to solve pricelist issue. And we try to solve other context variables issues as they come in.<br>
 '''''lescano''''': Anyway , I'll keep thinking of another way to solve the context variables issue. Thank you very much Carlos, have a nice end of day<br>
 '''''CarlosRuiz''''': thanks to you Alan<br>
 '''''junooni''''': is there any user of adempiere from UAE<br>