IDempiere/FullMeeting20150617
⇐ Table of Contents | 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)
