IDempiere/FullMeeting20120711
⇐ Table of Contents | Full Meeting Minutes | Full Meeting 2012-07-11
CarlosRuiz: Hi, good day
hahmed: Hello
a42niem: hi
mzuniga_ergio: Hi Carlos
Edwin_Ang: hi everyone
hahmed: Hi Edwin
CarlosRuiz: I'll be checking JIRA issues - please let me know if you're interested in any specific issue to review
hahmed: CarlosRuiz: I have a few issues for you to review
hahmed: Can we start with IDEMPIERE-101
CarlosRuiz: sure
CarlosRuiz: seems straight - will test it ...
hahmed: Edwin I have added a dependency to jasper and jasper-library to org.adempiere.server to resolve IDEMPIERE-214
hahmed: CarlosRuiz: can you also review IDEMPIERE-214
hahmed: and IDEMPIERE-335, I think they are important since till now sending jasper reports via workflows or scheduler was not working
CarlosRuiz: Hahmed, looking the changes on 214 and 335 - would it be possible to change ReportEngine.get instead?
hahmed: CarlosRuiz: I looked into it and yes it is possible to change ReportEngine.get but since Jasper Reports don't really need and most of the time don't have PrintFormat it might result in unexpected results since everywhere ReportEngine.get is called, its generally to get the PrintFormat
hahmed: it would work for Forms thought (since they have Print Format and Jasper linked to Print Format)
CarlosRuiz: yes, and you don't have the pinstance on the get for forms
CarlosRuiz: on https://bitbucket.org/hahmed/idempiere/changeset/5f33b56d79d0
CarlosRuiz: I think you have some copy-paste errors on pi.setRecord_ID
hahmed: Oops yes
CarlosRuiz: reading https://bitbucket.org/hahmed/idempiere/changeset/56ae246dc7cc
CarlosRuiz: the line if(process.getJasperReport() != null)
CarlosRuiz: maybe must be something like?
hahmed: yes
CarlosRuiz: if(process.getJasperReport() != null || re.getPrintFormat().getJasperProcess_ID() > 0)
hahmed: well the problem here is we can have reports that don't have a printformat, just jasperprocesses
CarlosRuiz: I mean - if the process doesn't have attached jasper, but the print format do?
hahmed: yeah makes sense
hahmed: then we have to move ReportEngine re = ReportEngine.get(m_schedulerctx, pi);
hahmed: before the if block
CarlosRuiz: yep - and we can have that process without print format - so we need to check for nulls too
hahmed: only for non jasper reports
hahmed: so if we just move the ReportEngine re = ReportEngine.get(m_schedulerctx, pi); before if block
hahmed: and change if to what you suggest
hahmed: it should be fine
CarlosRuiz: well it must check also re == null
CarlosRuiz: to avoid the possible NPE
hahmed: yes only inside the else block
CarlosRuiz: right
hahmed: yeah
hahmed: Anyway if the general idea seems fine to you I can fix the minors
CarlosRuiz: yes - sounds fine
hahmed: ok good, can you next check http://jira.idempiere.com/browse/IDEMPIERE-336
hahmed: its a new process
hahmed: I think there is genuine need for it
CarlosRuiz: looks fine at first sight
CarlosRuiz: I'll try to test it too
hahmed: sure, though it has been tested in production for a couple of weeks now
CarlosRuiz: good
hahmed: next if you can read my comments and changeset for http://jira.idempiere.com/browse/IDEMPIERE-236
CarlosRuiz: you can add that info to the ticket :-) that is being used in prod by your users
CarlosRuiz: ah, yes, I saw your comments, thanks for pointing us there
hahmed: another one is http://jira.idempiere.com/browse/IDEMPIERE-103
hahmed: simple change, and since the invoice to be deleted is in progress should not have any accounting consequences
hahmed: again this is in use in production for months
CarlosRuiz: ...
CarlosRuiz: MInOutLine.setIsInvoiced must not be set because the invoice has not been completed
hahmed: CarlosRuiz: it gets set for InProgress invoices by the generate Invoice processes
hahmed: even if the status is set to prepare, which is ok since otherwise there is no way to link the invoiceline to inoutline
CarlosRuiz: I see
Edwin_Ang: hahmed: i have some interest about IDEMPIERE-336
Edwin_Ang: do you add any validation to restrict requisitions that has been converted to rfq?
hahmed: Edwin_Ang: no, not at this stage, I didn't want to change the M_Requisition or C_RfQLine tables, wanted minimum intrusion, but it would be a good idea to add c_rfqline_id or c_rfq_id columns to m_requisition or M_requisition_line
hahmed: this would allow matching the rfq to requisition
Edwin_Ang: i am thinking of a new table MatchRequisition
Edwin_Ang: it can be used for matching PR and PO too
hahmed: That will be a good idea as well, we are currently facing this issue that Requisition can not be matched to PO unless its created using Create PO from requisition process
hahmed: in fact its something I will work on next week
hahmed: i was simple thinking of PO to Requistion match, but now will go for PO-Requisition-RfQ match
Edwin_Ang: well.. previously i have worked on a "create lines from" requisition lines to po lines
Edwin_Ang: we can work together on this
hahmed: sure would be great
Edwin_Ang: i just have to add the code to create new entries on MatchRequisition
Edwin_Ang: but.. do the others agree on this new db structure?
hahmed: Carlos? is it ok to add c_rfqline_iq to m_requisitionline? this would be only change i believe
CarlosRuiz: can a requisition line be associated to more than one rfq line ?? I mean, in business life?
Edwin_Ang: hahmed: i am talking about the new table MatchRequisition
hahmed: oh ok, yeah that would be non intrusive to existing tables
Edwin_Ang: it will allow a three way matching between requisition, rfq, and po
hahmed: yeah that is better indeed
Edwin_Ang: but this change will not be backward compatible
Edwin_Ang: we will change the relationship between PR and PO
hahmed: anyone interested in http://jira.idempiere.com/browse/IDEMPIERE-320 maybe its my personal preference
CarlosRuiz: Edwin_Ang, why not backward compatible?
hahmed: Carlos because currently the PO and PR match is via c_orderline_id in m_requisitionline
Edwin_Ang: cos currently it is a one to many relationship between req lines and po lines
Edwin_Ang: i am proposing to move the relationship to MatchRequisition table
Edwin_Ang: to allow many to many relationship between pr lines and po lines
CarlosRuiz: yes, but it's not breaking old behavior
CarlosRuiz: just extending it
CarlosRuiz: if you provide a migration script that fill the new table based on the old structure then it's compatible
CarlosRuiz: or I am interpreting wrongly?
hahmed: Carlos what would we do for a PR line which has two PO lines
hahmed: currently, when we generate PO from PR
hahmed: a single POline contains the quantity from PR line and they are linked using c_orderline_id columns in m_requisitionline
Edwin_Ang: @hahmed: currently we can't do one PR line match two PO lines
hahmed: yes thats what I am saying
Edwin_Ang: that's why i am proposing MatchRequisition for such requiremetn
hahmed: if we use MatchRequisition table it would allow us to create multiple PO lines for single PR or the other way around create single PO line for multiple PR lines
Edwin_Ang: @Carlos: you are right.
Edwin_Ang: although i find it easier to write a adempiere process than a sql migration script for that purpose :D
CarlosRuiz: sounds like an "insert as select"
CarlosRuiz: you can use nextidfunc to generate the sequence IDs on sql
hahmed: sounds good
nmicoud: Hi everyone
nmicoud: CarlosRuiz, if you still get some time, can you please review http://jira.idempiere.com/browse/IDEMPIERE-328 (will not take long), then http://jira.idempiere.com/browse/IDEMPIERE-332 (enhancement for document sequences, you may have to take some aspirin!)
Edwin_Ang: so hahmed, how are we going to work on this?
Edwin_Ang: anyway, a question to everyone
hahmed: yes Edwin just let me know what you want me to work on
Edwin_Ang: last year, i have reported a weird bug on ZK
hahmed: if you have something already we can add on add
hahmed: *add on that
Edwin_Ang: @hahmed: i'll extract my previous code and put it in a new project then i'll invite you to work on it
Edwin_Ang: how about that?
hahmed: good with me
Edwin_Ang: back to the ZK bug, occasionally after some usage, the create new toolbar button a random window will grey out
CarlosRuiz: 328 -> OK, seems fine
Edwin_Ang: back then i almost pull my hair out
Edwin_Ang: until hengsin suggest me to comment out the window caching code on Ini.java
Edwin_Ang: i've tried with various version of globalqss361 and still i am experiencing this bug
Edwin_Ang: the weird thing is i never read any report from anyone
CarlosRuiz: nmicoud, on 332, the 2pack was already replaced by the migration scripts?
nmicoud: no
nmicoud: i wait for an approval of dictionnary modification before making migration script
hahmed: nmicoud: I don't think u need an approval for using id generator or do you? well I don't think we can run out of numbers easily
nmicoud: yep, there are some thousand which are available ;-) ; but since it is a deep modification, i'd prefer to have a peer review before making those scripts
CarlosRuiz: I think is fine - you can generate the migration scripts better - easier to test from here
nmicoud: while developing, i made some mistakes in code and i couldn't log in
nmicoud: ok, i'll do this and attach them to the ticket
hahmed: sorry for repeating, but any input on http://jira.idempiere.com/browse/IDEMPIERE-320 I don't think a lot of people using Swing client anymore!
CarlosRuiz: ah yes - I was reading that
hahmed: I can not open up to the ZK UI till now!
CarlosRuiz: I'm fine with the Shift+Tab and Shift+Enter approach - can you make it configurable?
hahmed: yes can be made configurable
CarlosRuiz: tenant sysconfig I guess - or system?
hahmed: whatever you recommend
CarlosRuiz: I guess per tenant can be done in this case
hahmed: ok will do that
hahmed: so regarding the Create RfQ from Requistion, lets wait for the MatchRequisition work to complete, I will modify the process to add lines to Match table and then we can integrate it
hahmed: the jasper via workflow and scheduler I will do the minor fixes and changes and then maybe Carlos can integrate them
CarlosRuiz: ok
Edwin_Ang: no response from anyone, meaning no one is experiencing the same issue with ZK toolbar?
CarlosRuiz: yes, I think from time to time I have heard that problem
Edwin_Ang: well.. do you have any idea where i can't check for that bug?
CarlosRuiz: I think it must be related with the same context issues that we have confronted in past
Edwin_Ang: it is related with window caching
Edwin_Ang: the current workaround is to disable window caching
Edwin_Ang: maybe that can be our starting point to search for the bug?
hahmed: Is anyone working on P2 update repository functionality for iDempiere?
hahmed: it is a MUST before 1.0 IMO
hahmed: would be very difficult to deploy updates or enhancements to large deployments
Edwin_Ang: got to go now
CarlosRuiz: thanks Edwin, bye
Edwin_Ang: @hahmed: i will work on the initial project tomorrow, just wait for my invitation :)
Edwin_Ang: ok.. bye, carlos
hahmed: ok
hahmed: CarlosRuiz: Only you and Heng Sin have the commit rights to idempiere right?
CIA-93: iDempiere: hesham * e29901d3b08d r7386 /org.adempiere.ui.swing/src/org/compiere/grid/ed/VImage.java:
CIA-93: iDempiere: IDEMPIERE-101
CIA-93: iDempiere: (transplanted from https://bitbucket.org/hahmed/idempiere/changeset/bf7a7476f826)
CarlosRuiz: yes hahmed - the idea is that anybody can have his/her own fork and contribute via patches or pull requests
hahmed: ok good
hahmed: ok time for me to leave as well
CarlosRuiz: thanks Hesham
hahmed: I will fix the minors and put the changeset in the issues
hahmed: thanks and bye
CarlosRuiz: bye
buildmaster: Project iDempiere build #237: FAILURE in 2 min 31 sec: http://jenkins.idempiere.com/job/iDempiere/237/
buildmaster: hesham: IDEMPIERE-101
buildmaster: (transplanted from https://bitbucket.org/hahmed/idempiere/changeset/bf7a7476f826)
CIA-93: iDempiere: dantam * ed91f0c0af46 r7387 /org.adempiere.plugin.utils/src/org/adempiere/plugin/utils/AdempiereActivator.java:
CIA-93: iDempiere: http://jira.idempiere.com/browse/IDEMPIERE-298
CIA-93: iDempiere: Make org.adempiere.plugin.utils.AdempiereActivator more overridable
CIA-93: iDempiere: hahmed * 914ac1c92b42 r7388 /org.adempiere.base/src/org/compiere/model/MInvoice.java: IDEMPIERE-103 - In progress invocies can not be deleted if linked with an Order
buildmaster: Yippie, build fixed!
buildmaster: Project iDempiere build #238: FIXED in 15 min: http://jenkins.idempiere.com/job/iDempiere/238/
buildmaster: dantam: http://jira.idempiere.com/browse/IDEMPIERE-298
buildmaster: Make org.adempiere.plugin.utils.AdempiereActivator more overridable
CIA-93: iDempiere: nmicoud * 65cb3a366f73 r7389 / (2 files in 2 dirs): IDEMPIERE-85 : Add confirmation on TreeMaintenance when moving all nodes
CIA-93: iDempiere: nmicoud * a317cd1bc689 r7390 / (4 files in 4 dirs): IDEMPIERE 85 - Add confirmation on TreeMaintenance when moving all nodes
CIA-93: iDempiere: nmicoud * 3995b14d0c27 r7391 /migration/360lts-release/ (2 files in 2 dirs): Complete Window Customization - Cant save records on AD_UserDef_Field
CIA-93: iDempiere: globalqss * 6792bf7eb4ec r7392 /migration/360lts-release/ (4 files in 2 dirs): Fix latest migration scripts
