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
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
aguerra: hi everybody
aguerra: good morning!!!
CarlosRuiz: Hi aguerra
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
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
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
lescano: seems to solve pricelist issue. And we try to solve other context variables issues as they come in.
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
junooni: is there any user of adempiere from UAE