CarlosRuiz: full meeting

2012-10-24T15:48:43Z

full meeting

New page

⇐
[[IDempiere|Table of Contents]] |
[[IDempiere/Full Meeting Minutes|Full Meeting Minutes]] |
Full Meeting 2012-10-24


'''''CarlosRuiz''''': Good morning 
'''''nmicoud''''': Bonjour 
'''''CarlosRuiz''''': Nicolas - I created the peer review status on JIRA 
'''''CarlosRuiz''''': and created this search 
'''''CarlosRuiz''''': http://jira.idempiere.com/secure/IssueNavigator.jspa?mode=hide&requestId=10300 
'''''nmicoud''''': Fine 
'''''nmicoud''''': That will be clearer 
'''''CarlosRuiz''''': will try today to review fixed assets 
'''''nmicoud''''': ok, if you got some times, could you please have a look at http://jira.idempiere.com/browse/IDEMPIERE-463 ? 
'''''Edwin_Ang''''': hi everyone 
'''''CarlosRuiz''''': ah yes - I have seen that problem with Table reference 
'''''CarlosRuiz''''': Hi Edwin_Ang 
'''''nmicoud''''': Hi 
'''''CarlosRuiz''''': with references you just can display Name and there is a checkbox for Value 
'''''nmicoud''''': you can choose what column to show (Name, DocumentNo, ...) and only a checkbox for Value 
'''''nmicoud''''': Maybe adding a new checkbox to say "Show identifiers" or if ID is selected, show table identiers 
'''''CarlosRuiz''''': yes - I don't like that 
'''''CarlosRuiz''''': :-) was thinking the same - flag to "Show identifier" 
'''''hengsin''''': nmicoud, "Display=C_Invoice_ID" so it only show ID 
'''''CarlosRuiz''''': hmm - the ID also sounds ok - as that's usually how an ID is shown 
'''''nmicoud''''': yes 
'''''nmicoud''''': for hengsin and carlos 
'''''CarlosRuiz''''': just made some tests on demo.idempiere.com - effectively choosing the ID - shows just the ID :-) as expected 
'''''nmicoud''''': :d 
'''''CarlosRuiz''''': I guess that sounds like a good approach - ID shows the identifier 
'''''CarlosRuiz''''': Edwin_Ang, how are things going with the M_Storage changes? 
'''''Edwin_Ang''''': to be honest i haven't made any good progress 
'''''Edwin_Ang''''': i am not very sure with the design yet 
'''''Edwin_Ang''''': currently, i believe that the issue is only with qtyreserved 
'''''Edwin_Ang''''': even if we don't drop M_Storage it won't be any issue 
'''''Edwin_Ang''''': what we should do is take out qtyordered and qtyreserved and find a place for both 
'''''CarlosRuiz''''': yes - M_StorageReservation 
'''''Edwin_Ang''''': qtyordered won't present any issue, even if we just use sum(qtyordered) from c_orderline, it should be of no issue 
'''''CarlosRuiz''''': yes - most of the problems are on sales 
'''''CarlosRuiz''''': but still don't get what is the design doubt 
'''''Edwin_Ang''''': test 
'''''Edwin_Ang''''': sorry, connection problem 
'''''CarlosRuiz''''': np - I was saying that "still don't get what is the design doubt" 
'''''Edwin_Ang''''': well last week, hengsin told me that product reservation must really mean that: those products are "claimed" 
'''''Edwin_Ang''''': they cannot be transacted by other document 
'''''Edwin_Ang''''': do we agree with that? 
'''''CarlosRuiz''''': partially - there are still rules to "Force" using inventory 
'''''CarlosRuiz''''': but yes - that's the idea of reservation 
'''''red1''''': i think previously 'availability' was more important 
'''''red1''''': reservation need not be tightly 'reserved' but still open to be taken by a confirmed SO 
'''''red1''''': that means if reservation = 3, available = 2. Then an SO will make it res = 2 available = 2 
'''''red1''''': sorry i think its res = 3 .. available = 1 
'''''red1''''': available is more important category to watch 
'''''Edwin_Ang''''': well.. if you put in on a user's perspective 
'''''Edwin_Ang''''': let say i am the user 
'''''Edwin_Ang''''': i have successfully reserved 1 unit of item X 
'''''Edwin_Ang''''': but then, the warehouse staff told me that they are out of stock 
'''''Edwin_Ang''''': because some other guy has put one big order and rushed to the warehouse to take those items 
'''''Edwin_Ang''''': then what is the meaning of reservation? 
'''''CarlosRuiz''''': I think standard orders don't allow the other guy to reserve more than available 
'''''CarlosRuiz''''': but the force rule - and other types of orders can override that check 
'''''Edwin_Ang''''': ow, sorry wrong case.. trying to remember past cases :D 
'''''Edwin_Ang''''': how bout if the other guy move those items to another warehouse? 
'''''CarlosRuiz''''': yep - movements and internal use are not checking reservations 
'''''fjvr''''': Movement between warehouse should use reserve 
'''''CarlosRuiz''''': but we can add that in a future step - trying to keep it simple on this first step 
'''''Edwin_Ang''''': actually i want to do as you suggest - keep it simple on the first step 
'''''fjvr''''': Ticket ID-385 says that the table is locking up. What does that mean and how can it be recreated? 
'''''Edwin_Ang''''': but then if movement or internal use should check reservation then M_StorageReservation should have M_Locator_ID 
'''''Edwin_Ang''''': and the query will be very different from only using M_Warehouse_ID 
'''''CarlosRuiz''''': I think in future movement and internal use could check reservation at warehouse level 
'''''CarlosRuiz''''': so, you can move items within your warehouse - but not out 
'''''CarlosRuiz''''': sorry - that's for movement :-) 
'''''CarlosRuiz''''': internal use must check in future at warehouse level too - to avoid negative availability on a warehouse 
'''''Edwin_Ang''''': why do you prefer check at warehouse level than locator? 
'''''Edwin_Ang''''': i think the issue with IDEMPIERE-385 is because reservation and onhand is on the same table 
'''''Edwin_Ang''''': somehow i see the relation between storage and reservation is one to many 
'''''CarlosRuiz''''': in most cases - at reservation time you don't know (and don't need to know) which locator will attend the shipping 
'''''CarlosRuiz''''': and indeed what happens on idempiere (since compiere times) is that you put the reservation on a locator - and then attend the shipping with a different locator 
'''''CarlosRuiz''''': leading to those confusing negatives 
'''''Edwin_Ang''''': yes.. in case of sales order, i agree with you 
'''''Edwin_Ang''''': that's why i agree with the addition of M_ReserveLocator_ID on M_Warehouse 
'''''Edwin_Ang''''': to serve this purpose 
'''''Edwin_Ang''''': but for movement and internal use? 
'''''CarlosRuiz''''': ah - I see you already committed code for this on your repository :-) 
'''''Edwin_Ang''''': just partial work 
'''''CarlosRuiz''''': movement and internal use - can check in future that the global warehouse availability for a product cannot be negative 
'''''Edwin_Ang''''': well.. then how do we calculate qtyavailable for this case: 1 warehouse have 2 locators 
'''''Edwin_Ang''''': locator A have 30 units of product X, locator B have 20 units of product X 
'''''Edwin_Ang''''': reservation is 15 units of product X 
'''''Edwin_Ang''''': what is the qtyavailable for locator A and locator B? 
'''''fjvr''''': jeje 
'''''CarlosRuiz''''': what is the qtyavailable for warehouse? -> 35 
'''''CarlosRuiz''''': so - suppose we implement this in future - if you try to consume (internal use) 16 items - that will error 
'''''CarlosRuiz''''': same if you try to move 16 items out of that warehouse 
'''''CarlosRuiz''''': but you can be allowed to move 16 items from locator B to A without problem 
'''''CarlosRuiz''''': in the end - availability per locator is useless - we're adding M_ReserveLocator_ID just as backward compatibility on reports - but is unnecessary 
'''''Edwin_Ang''''': you mean 36 or 16? 
'''''CarlosRuiz''''': ah yes - I made all the calcs as if reserv=35 :-) sorry 
'''''hengsin''''': availability per locator is too fine grained in practise - you just need to make sure you don't oversell what is in your warehouse. 
'''''hengsin''''': i means most of the time that's what the user want. so to keep it simple at least initially, we should only cater for this. 
'''''Edwin_Ang''''': ok, if there is no qtyavailable at locator level then i am ok with it 
'''''Edwin_Ang''''': and hengsin, i would like to ask you about that forUpdate() method 
'''''Edwin_Ang''''': it is not implemented in adempiere361, so i just get it from idempiere 
'''''Edwin_Ang''''': is there any downside of this locking? 
'''''Edwin_Ang''''': and how should i set the timeout parameter? 
'''''hengsin''''': you need locking to ensure you are not working with stale data. 
'''''hengsin''''': Edwin_Ang, you means what should the appropriate value for timeout ? 
'''''Edwin_Ang''''': yes, what is the appropriate value? 
'''''Edwin_Ang''''': i am seeming many places need these kind of locks.. open balance, bank account balance, storage, reservation 
'''''fjvr''''': What is the effect of a lock? 
'''''hengsin''''': so that people can't change it while you use the number to perform calculation 
'''''fjvr''''': Ah, gotcha, ok, understood 
'''''hengsin''''': Edwin_Ang, we can try with 30 seconds but that's usually something you need to fine tune for your production site. 
'''''fjvr''''': Definately if a document is complete you should not be able to change. Maybe even if it is in the prepared state you should not be able to change it. 
'''''Edwin_Ang''''': so, this should be parameterized? 
'''''Edwin_Ang''''': like a sysconfig parameter? 
'''''CarlosRuiz''''': that timeout is to give up if it cannot get the lock 
'''''CarlosRuiz''''': Edwin_Ang, do you have the URL where I can get your published Fixed Assets manual? 
'''''CarlosRuiz''''': I think you posted that on forums but cannot get it 
'''''Edwin_Ang''''': a moment pls 
'''''CarlosRuiz''''': ah - found it 
'''''CarlosRuiz''''': https://bitbucket.org/edwin_ang/fixed_assets/downloads 
'''''fjvr''''': Good writing style btw. It is an enjoyable read. 
'''''hengsin''''': Edwin, yes, good to make that a sysconfig parameter. 
'''''fjvr''''': The idea of the assets emerging out of projects was very good and definately a must. 
'''''Edwin_Ang''''': @fjvr: thx for the compliment :) 
'''''Edwin_Ang''''': so the timeout does not control the lock? 
'''''Edwin_Ang''''': the lock is automatically released at what event? 
'''''hengsin''''': commit or rollback 
'''''fjvr''''': good bye fellows, have a good day/afternoon or night ! 
'''''Edwin_Ang''''': i see 
'''''Edwin_Ang''''': so just executing save() should do that rite? 
'''''CarlosRuiz''''': no - when committing the trx 
'''''CarlosRuiz''''': if is out of trx (trx=null) then save do the commit 
'''''Edwin_Ang''''': i see 
'''''Edwin_Ang''''': any reason why forUpdate() is not committed to 361? 
'''''Edwin_Ang''''': cos i think it is critical 
'''''CarlosRuiz''''': is not backported 
'''''CarlosRuiz''''': there are many improvements on idempiere that have not been backported - and no plans to do that 
'''''CarlosRuiz''''': but I see you integrated forUpdate in your branch - so - you're backporting it 
'''''Edwin_Ang''''': yes 
'''''Edwin_Ang''''': and actually i want to propose that 361 being released as iDempiere 1.0 
'''''Edwin_Ang''''': the current iDempiere as iDempiere 2.0 
'''''nmicoud''''': gtg, bye bye 
'''''CarlosRuiz''''': thanks Nicolas 
'''''Edwin_Ang''''': is it possible to do so? 
'''''CarlosRuiz''''': I think the two project are too different - 361 is more like an Adempiere-Transition than an iDempiere by itself 
'''''CarlosRuiz''''': so IMHO it would be confusing 
'''''red1''''': Edwin_Ang: on another matter, the FA.. are you going to release the changes as 2Pack? 
'''''red1''''': if so i can help make it into a plugin for iDempiere 
'''''red1''''': then we can see the benefit of OSGi in action 
'''''red1''''': but your DB changes should not alter core tables or remove any field 
'''''Edwin_Ang''''': i think FA should be included in the core 
'''''CarlosRuiz''''': red1 - the plan is to integrate FA in core 
'''''red1''''': yes.. but the idea is as a modular plugin rite? 
'''''red1''''': so if that is the case (in core) i guess the DB changes can be permanent 
'''''red1''''': that will make it a core plugin 
'''''Edwin_Ang''''': @Carlos: but you should think of a solution for the existing installations 
'''''red1''''': i was thinking of a more transient plugin where other FA plugins can interchange later 
'''''Edwin_Ang''''': iDempiere is a major change 
'''''Edwin_Ang''''': and many new users are still trapped with 370 
'''''Edwin_Ang''''': only developers know how to find 361 
'''''CarlosRuiz''''': Edwin - we could try to make a "final" release of 361 if that ease things for some people 
'''''Edwin_Ang''''': and that final release will be named as adempiere of idempiere? 
'''''CarlosRuiz''''': I would call that Adempiere-Transition 
'''''CarlosRuiz''''': I'm not too concerned about people that chose 370 - is their choice - and our goal is not to kill adempiere :-) 
'''''CarlosRuiz''''': good if people have choices 
'''''Edwin_Ang''''': many choose because lack of knowledge 
'''''Edwin_Ang''''': it is good if we can do them a favor 
'''''Edwin_Ang''''': being able to choose a stable product to use rite? 
'''''CarlosRuiz''''': I would say more like "lack of marketing" from our side :-) but I'm not interested on doing that - it would be for community to share such knowledge on forums 
'''''Edwin_Ang''''': we can do that.. but we need a tag release for that 
'''''Edwin_Ang''''': not everyone should learn mercurial :D 
'''''CarlosRuiz''''': that's the good thing about recent red1's work 
'''''CarlosRuiz''''': but yes - I understand your concerns 
'''''Edwin_Ang''''': yes.. red1's windows installer is a very good thing 
'''''Edwin_Ang''''': but we still need that tag release 
'''''CarlosRuiz''''': I'm trying to avoid politics on this weekly meeting space - so I would just suggest - be happy that you have the knowledge about what is happening - share that knowledge if possible - and be patient ;-) 
'''''Edwin_Ang''''': it is better for community building 
'''''CarlosRuiz''''': hehehe - partially joking there - I hope you understand 
'''''Edwin_Ang''''': no.. don't get it wrong. this is not politics 
'''''Edwin_Ang''''': i don't like that thing too 
'''''CarlosRuiz''''': anyways - I think we're close to tag a first release 
'''''CarlosRuiz''''': or better for a first preview release 
'''''CarlosRuiz''''': the biggest changes I think are done - so is worthy to work on that 
'''''CarlosRuiz''''': another thing that we want to implement (suggestion from hengsin) is to stop reserving the migration numbers - and use a datetime prefix instead 
'''''CarlosRuiz''''': that would be applicable after the first release 
'''''Edwin_Ang''''': and what is your plan for 361 after the first release? 
'''''CarlosRuiz''''': just bug fixes 
'''''Edwin_Ang''''': bug fixes are enough 
'''''CarlosRuiz''''': although 361 can serve for some time for the purpose of receiving contributions from people that still haven't migrated (it is serving such purpose actually) 
'''''Edwin_Ang''''': it is still the most stable version 
'''''Edwin_Ang''''': and existing installation won't migrate very soon to the new iDempiere 
'''''Edwin_Ang''''': because there are too many major changes 
'''''CarlosRuiz''''': yep - sure there will be a long transition time - that's why some bug fixes maintenance is important 
'''''CarlosRuiz''''': if you call something LTS - the idea is to provide support - not just tag something 370LTS and do not provide any patch ;-) 
'''''CarlosRuiz''''': ah sorry - 370 is just an example I could have said 978 - hehehe 
'''''CarlosRuiz''''': Edwin_Ang, I already merged your FA commits - and I'm in the process of reviewing - thanks a lot for that work 
'''''Edwin_Ang''''': ah.. i won't comment on that :D 
'''''CarlosRuiz''''': thanks everybody for attending the meeting - I need to move out for a while 
'''''Edwin_Ang''''': ok 
'''''Edwin_Ang''''': i got to go too 
'''''Edwin_Ang''''': thanks for the meeting 
'''''Edwin_Ang''''': bye everyone

IDempiere/FullMeeting20121024 - Revision history

CarlosRuiz: full meeting