From WikiQSS

Table of Contents | Full Meeting Minutes | Full Meeting 2012-09-12

CarlosRuiz: Good Morning
a42niem: hi Carlos
mzuniga_ergio: Good Morning
dpansheriya: Hello Carlos
nmicoud_: Bonjour
dpansheriya: Good Morning Everybody
peter09: Hi everybody
CarlosRuiz: Nicolas, finally I integrated the org+month doc sequence - I think it's great improvement - thanks about that
nmicoud_: you're welcome
nmicoud_: i've also integrate it in the customer site and it seems to work fine!
CarlosRuiz: I'll check some JIRA tickets pending for review - please let me know if you want some specific
nmicoud_: I've uploaded some patchs for some tickets, let me check
red1: Hola CarlosRuiz
red1: Good news from Tokyo here as we just concluded an interview with the top online IT publisher about Adempiere Japan
CarlosRuiz: nice pictures on your fb
nmicoud_: 417 and 229 have a patch ; 82 ask a question and 382 still a pb
nmicoud_: Sound good red1 ! i'm following your adventures with interest
CarlosRuiz: ok - As Jack would say, let's go by parts ... checking 417 first
nmicoud_: Who's Jack ?
CarlosRuiz: :-) gallows humor
CarlosRuiz: jack the ripper
nmicoud_: :d
nmicoud_: i like this kind of humor
CarlosRuiz: can't find the patch on 417
nmicoud_: forget to CTRL+V
CarlosRuiz: :-) got it
CarlosRuiz: about 382 - I haven't reviewed in code - but I guess solution could be something like marking the record as changed when you push the "new" button
CarlosRuiz: it seems like is marked as changed just when you touch a field - so, and not when all fields are filled with default values
nmicoud_: yes, that could work
nmicoud_: it could be like a partial save
peter09: Hi everyone, my name is Peter and I am new to idempiere, but not so new to OSS.
peter09: Could I ask some questions?
CarlosRuiz: sure
peter09: To make long story short, I am starting up a company and I am looking for an ERP for "internal" usage.
peter09: Is there a release road map for idempiere 1.0?
CarlosRuiz: yes - planned date for 1.0 is Q1-2013
peter09: I see
CarlosRuiz: but there is a transition version that can be used right now
peter09: ok, will there be an "easy" migration path?
CarlosRuiz: yes - it will - just avoid using the things that are being deprecated
CarlosRuiz: like libero manufacturing or cash journals
peter09: are those functionalities marked in the source code?
CarlosRuiz: most of things that are being deprecated are marked as beta in dictionary on transition version
CarlosRuiz: with probably the big exception of cash journals
CarlosRuiz: where are you from?
peter09: Berlin
CarlosRuiz: ah - Dominik ( banym ) and Dirk ( a42niem ) are close to you
peter09: thats nice
peter09: I have read some things about adempiere/idempiere etc...
peter09: but it is a coincidence that I am in Berlin too ;)
CarlosRuiz: learning curve of these systems is steep - I would advice to try to get help from experienced implementors - like them
peter09: already noticed that...
peter09: the menu structure is quite overwhelming in 3.7
peter09: Are there some books or documentation on "business modeling" with idempiere?
peter09: As I have seen there is only one for adempiere which is quite old by now.
CarlosRuiz: I haven't used 3.7 - so don't know how it is - but I suppose it has not changed a lot - the book can help you to understand the basics and that's helpful for any version
red1: u can read more from forum on why we do not use 3.7, i guess u know that already
red1: Bayu's book of 3.4 is good enough and its the starting gospel u must go thru first
red1: must = should
peter09: ok, thanks for the info
CarlosRuiz: nmicoud_, having problems here testing 417
nmicoud_: what happens ?
CarlosRuiz: I think changing the BPL on MLocation afterSave is not good
CarlosRuiz: test case is like this: on location tab on BP - change the phone and then push the location button to change it
nmicoud_: i see.... :(
CarlosRuiz: as the location button changes the record on an independent trx - then you cannot save the location changes - and they are not reflected on your tab until you refresh
CarlosRuiz: so, I think the change must be on MBPartnerLocation.beforeSave
CarlosRuiz: actually it just assign the name if it's a new record
CarlosRuiz: so, we need to change it to assign the name also for update - but not always - maybe we can check if the location has changed more recently than the BPL
nmicoud_: think that we can open VLocationDialog from any C_Location_ID field
CarlosRuiz: this is if Location.Updated > BPL.Updated
nmicoud_: but if you just open VLocationDialog from BPL ; you don't go through the beforeSave
CarlosRuiz: hmmm ... checking
nmicoud_: maybe we can force a save of BPL when opening VLocationDialog (if opened from BPL) ?
CarlosRuiz: ah - as the C_Location_ID doesn't change the record is not required to be saved
nmicoud_: if newRecord, it will set up name as "." ; then you create your location, save it ; and that is what is going to change the BPL name
CarlosRuiz: ah, I see on zk there is a provision for that - but not on swing
CarlosRuiz: WLocationEditor on zk -> line 184 -> "force Change - user does not realize that embedded object is already saved."
nmicoud_: i check
nmicoud_: so we should do the same for swing ?
CarlosRuiz: checking ....
CarlosRuiz: working on a patch indeed :-)
nmicoud_: Great !
CarlosRuiz: supposedly in swing there is the same line (378)
nmicoud_: line 37?
banym: hi all
CarlosRuiz: no, 378 of VLocation
CarlosRuiz: Hi Dominik
nmicoud_: i'm lost
CarlosRuiz: :-( is not working anyways
CarlosRuiz: I mean - in swing - line 378 - there is the same line for -> "force Change - user does not realize that embedded object is already saved."
nmicoud_: ah! yep, we should have same behaviour for swing and web
nmicoud_: you did your tests on web or swing ?
CarlosRuiz: both
CarlosRuiz: ok - made VLocation work - now the problem is that the save is smart and realize that nothing changed :-(
nmicoud_: that where my patch could be used ?
CarlosRuiz: no - because is in a different trx
nmicoud_: right
nmicoud_: can we force a refresh of current tab when closing VLocationDialog (if opened from BPL table) ?
CarlosRuiz: I made it work - changing the name to "." on the location editor
nmicoud_: and so name is always updated ?
CarlosRuiz: yes - and changed the MBPartnerLocation to set the name whenever it's a "."
nmicoud_: But, what would happen if you open VLocationDialog from another tab ?
nmicoud_: Then, BPL.Name will not be updated
CarlosRuiz: ah - interesting
CarlosRuiz: in such case your patch will do the work
nmicoud_: yep
nmicoud_: or maybe we can try to add trxName on VlocationDialog ; if null, => my patch ; if not null, we use it to save phone and update name ?
nmicoud_: no idea if it is realistic
CarlosRuiz: trying a different approach - we can pass the gridfield object to the location dialog to make decisions there
nmicoud_: means that you will update name within LocationDialog ?
CarlosRuiz: trying to
CarlosRuiz: nmicoud_, almost working
CarlosRuiz: we still have one point where is not updated - and is directly from Location window
nmicoud_: there you can only use MLocation.afterSave method
CarlosRuiz: yes - but doint that will break the changes on BPL dialog
nmicoud_: or can LocationDialog call a method that can be stored in MLocation class ?
nmicoud_: then LocDialog and locationWindow will be processed the same way
CarlosRuiz: I'll make another try checking the trx name
nmicoud_: or force a save before opening location dialog ? and store the update BPL Name in MLocation.afterSave
CarlosRuiz: nmicoud_, finally - I have a working patch
nmicoud_: great
nmicoud_: curious to see it
CarlosRuiz: will commit and integrate
CarlosRuiz: yours
CarlosRuiz: but first I'm checking 229
nmicoud_: ok
nmicoud_: hope it will be faster to review ;)
CarlosRuiz: it fixed the date - but not the BP Validation
nmicoud_: hmmm, weird,
nmicoud_: maybe i've forget to upload something
CarlosRuiz: ah no :-)
CarlosRuiz: I haven't fixed on 361
nmicoud_: phew :)
CarlosRuiz: yep - it worked
nmicoud_: good !
CarlosRuiz: pushed to 361 - great if you can conduct more tests on the location thing
nmicoud_: i'll integrate it on a test version
nmicoud_: and give feedback
nmicoud_: about ticket 82 (modify filename of attachment,, WDYT of adding a checkbox to add (or not) timestamp ?
CarlosRuiz: ah - I was thinking about something better - we could try to make the name format configurable
CarlosRuiz: something like the document prefix/suffix
nmicoud_: that would be perfect :)
CarlosRuiz: that you can use some context variables - and/or some predefined for current timestamp or random #
nmicoud_: it should handle translation
CarlosRuiz: or just support some predefined variables
CarlosRuiz: @Print_Format_Name@
CarlosRuiz: @CurrentDate@
CarlosRuiz: @CurrentDateTime@
CarlosRuiz: @DocumentNo@
CarlosRuiz: @Document_Name@
CarlosRuiz: @RandomNumber@
nmicoud_: Predinied variables should be enough ?
CarlosRuiz: and we could set the desired format on a sysconfig variable - per tenant maybe
nmicoud_: This name format configuration would be set on print format ?
CarlosRuiz: is it necessary per print format? I think is too much - is just to generate the name when attaching PDF - or maybe exporting
nmicoud_: i mean, where do you store the name configuration ?
CarlosRuiz: sysconfig tenant key?
nmicoud_: if you send an invoice to a customer, you just want to have Invoice1337.pdf ; but if it is a internal report, you may want to have Aging_20120912...Pdf
CarlosRuiz: don't know if it's possible to have one for reports and another for document formats
nmicoud_: that's why we can use AD_PrintFormat table ? With a defaultValue that could be set on SysConfig
CarlosRuiz: ah - that sounds possible - yes
nmicoud_: Default Value could be @Print_Format_Name@_@CurrentDateTime@
nmicoud_: maybe we can add @UserName@ ?
nmicoud_: and/or @UserValue@ ?
CarlosRuiz: yep - could be useful
nmicoud_: so default should be Default Value could be @Print_Format_Name@_@UserValue@_@CurrentDateTime@
CarlosRuiz: yes
nmicoud_: think about something on ticket 417 ; what happen if you click on AD_Org_Info.C_Location_ID ? (haven't downloaded you patch)
CarlosRuiz: no problem - I covered that - but will test it
nmicoud_: i was writing tests to do ; good if you covered it
CarlosRuiz: ah - location not working when I integrated to iDempiere - will require more tests and fixes
CarlosRuiz: hehehe - I was too aggresive with my patch
nmicoud_: no, frantic, frantic, frantic !!!!
CarlosRuiz: tic tic tic tic tic tic tic toc
nmicoud_: :d
CarlosRuiz: nmicoud_, before testing - better wait for my additional patch
nmicoud_: ok
CarlosRuiz: good - tested in bp - warehouse and org
nmicoud_: fine
CarlosRuiz: ok ready - I pushed to 361
CarlosRuiz: and now pushing to idempiere
nmicoud_: ok, will test it
nmicoud_: will also try to have a look on 382, keep you in touch
CarlosRuiz: thanks
CarlosRuiz: ok - thanks for attending - need to move to another task - thanks a lot - c u later
nmicoud_: bye bye