IDempiere/FullMeeting20120404

⇐ Table of Contents | Full Meeting Minutes | Full Meeting 2012-04-04

CarlosRuiz: Good morning
Edwin_Ang: test
CarlosRuiz: Hi
Edwin_Ang: hi carlos
CarlosRuiz: working here on pull request from Dirk for http://jira.idempiere.com/browse/IDEMPIERE-177
CarlosRuiz: but we're on meeting time so please feel free to interrupt me :-)
Edwin_Ang: this is the idempiere meeting right?
Edwin_Ang: no topic currently?
CarlosRuiz: nope - as usual - open topics - work in the middle if there are no topics
Edwin_Ang: well.. let me start one then
Nicolas__: Hi !
tbayen: Hi! :-)
Edwin_Ang: Hi Nicolas :)
Edwin_Ang: can anyone tell me, how to make model validator code to commit in the same transaction as document process?
CarlosRuiz: use po.getTrxname
tbayen: I use something like "CPreparedStatement stmt = DB.prepareStatement(sql, get_TrxName());". I would believe that this uses the global transaction if there is one.
Edwin_Ang: well.. i almost always use get_TrxName() on my code
tbayen: What let you believe this does not work?
Edwin_Ang: cos i ran into some random issue
Edwin_Ang: it rarely happens but it do happens
Edwin_Ang: most recently i am working on customizing lco withholding code
Edwin_Ang: i take Kittiu's code for thai localization too
Edwin_Ang: everything is running fine until i got a report
Edwin_Ang: the validation is TIMING_AFTER_COMPLETE on MAllocationHdr
Edwin_Ang: my invoice and payment are already flagged as ispaid
Edwin_Ang: while the docstatus on my allocation record is invalid
tbayen: If there is no transaction the return value of getTrxName() is null (or "", can't remember). If there is no value I would use the debugger to find the point where the flags are set and where the transaction is closed. But I am not used to this internals. Perhaps the gurus here may help.
CarlosRuiz: usually in model validator there is always a transaction - MWF* if is triggered from the docaction button - or POSave* if triggered by a non-trx saving record
tbayen: Hmmm... AFTER_COMPLETE sounds like - hmmm - "after complete". Perhaps you need another entry point for your code. Or you have to check the status of the database inside your own transaction.
Edwin_Ang: AFTER_COMPLETE is a valid TIMING.
Edwin_Ang: It is actually called within completeIt()
Edwin_Ang: i think i've been very carefully to always use po.get_TrxName()
tbayen: I know it is valid. I wanted to say that it may be that it is called after the transaction is closed. I did not read the source yet.
tbayen: I CarlosRuiz says "there is always a transaction" and you get a value from getTrxName() the transaction is valid. If not perhaps it has to do with the meaning of "after completion".
tbayen: If CarlosRuiz says "there is always a transaction" and you get a value from getTrxName() then the transaction is valid. If not perhaps it has to do with the meaning of "after completion".
Nicolas__: Carlos, have you been able to review patch for ticket 129 (restrictions on toolbar) ?
CarlosRuiz: sorry - I didn't notice you added a patch - we'll review it today
Nicolas__: ok, no problem
Edwin_Ang: i've just done a little test
Nicolas__: and btw, have you nay idea on how to deal with IDEMPIERE-38 (tabs with same translation) ? the behaviour is very very strange in swing
Edwin_Ang: i add a faulty DIVISION BY ZERO code on my validator method
Edwin_Ang: my payment and invoice is processed, while the allocation is invalid
CarlosRuiz: Nicolas__, the swing misbehavior is on 361 or idempiere?
Nicolas__: 361
Nicolas__: don't have tested in idempiere
Edwin_Ang: another test.. i add a validator code TIMING_BEFORE_PREPARE to set description on allocationHdr to "TEST BY EDWIN"
red1: Edwin_Ang: i wonder if u can debug by breaking in the Eclipse to see if TrxName changes..
Edwin_Ang: use saveEx() to save the record
Edwin_Ang: then add a faulty code on TIMING_AFTER_PREPARE
red1: if u think the TrxName seems to change
Edwin_Ang: bad news is the description is set
tbayen: Edwin_Ang, as far as I understand the source the validator is called insode the transaction and before setProcessed(). Perhaps you set a breakpoint on beginning of MAllocationHdr.completeIt() and debug it step by step.
Edwin_Ang: @red1, will try to debug the TrxName
red1: Or, somewhere there is a null for TrxName
tbayen: Edwin_Ang, do you have all the source inside Eclipse for debugging?
red1: usually it maybe a null instead of a TrxName… (that is all i can think of atm :> )
Edwin_Ang: tbayen: i have all the source
Edwin_Ang: currently try to debug this
Edwin_Ang: need a little help here
Edwin_Ang: i've never debugged a transaction
Edwin_Ang: where can i see the trxName?
CarlosRuiz: the timing_after_prepare returns the error msg?
tbayen: Edwin_Ang, I believe every PO Objekct carries it's transaction name in the field m_trxName
Edwin_Ang: ok, this is my test result
Edwin_Ang: even though i've returned an error msg on TIMING_AFTER_PREPARE, the code still proceed to completeIt()
Edwin_Ang: so, in the end, i have an invalid allocation with description "TEST BY EDWIN"
Edwin_Ang: and my payment is marked as paid
Edwin_Ang: can i confirm there's something wrong here?
CarlosRuiz: can you pastebin your failing ModelValidator?
CarlosRuiz: http://pastebin.com/
Edwin_Ang: i paste the url here?
Edwin_Ang: http://pastebin.com/gqUrvCb3
CarlosRuiz: testing ...
Edwin_Ang: ok
CarlosRuiz: Edwin - how are you testing it?
CarlosRuiz: completing a payment?
Edwin_Ang: using payment allocation form
Edwin_Ang: i allocate the payment to an invoice
CarlosRuiz: guessing that VAllocation is not calling workflow - but completing it directly - just a hunch
Edwin_Ang: well now you say so
Edwin_Ang: i remembered read several code like that o
Edwin_Ang: on forms
Edwin_Ang: you don't have any wf activity record on document processed this way
Edwin_Ang: so that's the culprit?
CarlosRuiz: not sure - just a hunch :-) reading Allocation - line 738 states calling WF
CarlosRuiz: are you sure you added MAllocationHdr to the initialize?
Edwin_Ang: of course
Edwin_Ang: i add those code to LCO_Validator :D
CarlosRuiz: sorry for the noob question - I always triple check :-)
Edwin_Ang: actually i've had several similar issues in the past
Edwin_Ang: usually with inventory related classes
Edwin_Ang: the MTransaction record is generated while the MInventory / MInOut class is invalid
tbayen: I have to go for a customer meeting. Hope, Carlos will help you. Thanks everyone for being here and cu!
CarlosRuiz: tried with a Payment and status is set to Invalid - let's check with Allocation
CarlosRuiz: cu tbayen
Edwin_Ang: cu
CarlosRuiz: got it
CarlosRuiz: Edwin - replicated the issue
CarlosRuiz: allocation is Invalid - and invoice is paid
Edwin_Ang: and the description is saved
Edwin_Ang: should i open a jira ticket for this?
CarlosRuiz: ah
CarlosRuiz: error
CarlosRuiz: Allocation.java line 741
CarlosRuiz: not checking the boolean return of processIt
CarlosRuiz: I've seen this in other classes
CarlosRuiz: Edwin - yes - please open a JIRA ticket - and please mention the culprit is not checking return of processIt - I'm seeing more classes with the same problem, like MCashLine, MJournalBatch, MInvoice .... etc
Edwin_Ang: created and assigned http://jira.idempiere.com/browse/IDEMPIERE-223 to Carlos
Edwin_Ang: if no checking on return of processIt() is the culprit then we have a lot of work to do
Edwin_Ang: i've seen them everywhere and i am used to code that way
CarlosRuiz: Edwin_Ang, attached a patch - can you check it please to see if it solves your problem
Edwin_Ang: no
Edwin_Ang: problem still persists
CarlosRuiz: I checked the division by zero and it worked fine after the patch
Edwin_Ang: sorry
Edwin_Ang: i applied at wrong project
CarlosRuiz: :-)
Edwin_Ang: let me test for one more time
Edwin_Ang: :D
Edwin_Ang: yess
Edwin_Ang: it's ok now
Edwin_Ang: this means we have to screen for every call to processIt() right?
CarlosRuiz: yes - processIt seems dangerous - it hides even exceptions
Edwin_Ang: if you need a hand, we can help with this
CarlosRuiz: sure please
CarlosRuiz: is about checking all classes for processIt without evaluation of the result
Edwin_Ang: i guess this is the answer to our long time issue
Edwin_Ang: missmatch on MTransaction with onhand qty
Edwin_Ang: anyway.. got to go now
Edwin_Ang: very many many thanks with the help, Carlos
Edwin_Ang: zuhri will have some work to do tomorrow :D
Edwin_Ang: bye everyone
Nicolas__: In Swing, we can do a .setFontBold(true) on CLabel ; is there something similar for Label in webUI ?
CarlosRuiz: sure - there must be - check how the labels are changed from red to black when they are required
Nicolas__: i went into Label class and find createMandatoryDecorator. But i though there was a simpler way to do this
Nicolas__: i've made this : ((Label)general).setSclass("mandatory-decorator-text"); now, my label is red. That's better ! i just can't find where in the code it is said that 'mandatory-decorator-text' = red ; any idea ?
CIA-126: iDempiere: a42niem * e151a81edbb2 r7125 / (8 files in 2 dirs):
CIA-126: iDempiere: IDEMPIERE-177
CIA-126: iDempiere: Complete Window Customization functionality
CIA-126: iDempiere: a42niem * f5f8f8c24a00 r7126 /org.adempiere.base/src/org/compiere/model/MUserDefWin.java:
CIA-126: iDempiere: IDEMPIERE-177
CIA-126: iDempiere: Corrected selection process
CIA-126: iDempiere: globalqss * 39512c924b2b r7127 /org.adempiere.base/src/org/compiere/model/ (6 files): IDEMPIERE-177 Model Generated for iDempiere
CIA-126: iDempiere: a42niem * ec963759fadc r7128 /migration/360lts-release/ (2 files in 2 dirs):
CIA-126: iDempiere: IDEMPIERE-177
CIA-126: iDempiere: Added missing migration scripts
CIA-126: iDempiere: a42niem * 9b79c1f0f06b r7129 / (5 files in 3 dirs):
CIA-126: iDempiere: IDEMPIERE-177
CIA-126: iDempiere: AD_Language and name for entry made optional
CIA-126: iDempiere: Caching best matching entry for UserDefWin
CIA-126: iDempiere: a42niem * 9e419dc5d7b4 r7130 /migration/360lts-release/postgresql/830_IDEMPIERE-177_Window_Customization.sql:
CIA-126: iDempiere: IDEMPIERE-177
CIA-126: iDempiere: Correction in migration script
CIA-126: iDempiere: globalqss * c14598a733e1 r7131 /migration/360lts-release/ (2 files in 2 dirs): IDEMPIERE-177 Complete Window Customization functionality / fix migration scripts
CIA-126: iDempiere: globalqss * 328210a8b4ef r7132 / (5 files in 3 dirs): IDEMPIERE-177 Complete Window Customization functionality - peer review and tests
CIA-126: iDempiere: globalqss * 904aaa72944d r7133 / (22 files in 9 dirs): merge IDEMPIERE-215
CIA-126: iDempiere: globalqss * b36fb52f8094 r7134 /migration/360lts-release/ (4 files in 2 dirs): IDEMPIERE-215 - renumber migration script