IDempiere/FullMeeting20141112 - Revision history

CarlosRuiz: drop JIRA notifications from log

2014-11-13T00:03:28Z

drop JIRA notifications from log

CarlosRuiz: full meeting

2014-11-13T00:03:06Z

full meeting

New page

⇐
[[IDempiere|Table of Contents]] |
[[IDempiere/Full Meeting Minutes|Full Meeting Minutes]] |
Full Meeting 2014-11-12


'''''CarlosRuiz''''': Good Morning 
'''''smartjsp''''': Good Morning Carlos ... 
'''''nmicoud''''': Bonjour 
'''''allgood''''': good morning 
'''''allgood''''': i had an idea, i do not know how doable is this i would like a help from you folks 
'''''allgood''''': it is regarding the ID and UUID on migration logs 
'''''allgood''''': does anybody tried to free us from depending on the ID on the migration logs? 
'''''CarlosRuiz''''': so, if you use UUIDs instead of IDs then migration scripts could be helpful for customizations too? 
'''''allgood''''': yes 
'''''allgood''''': but that is not the main idea 
'''''Not-57f0''''': [IDEMPIERE] norbert.bede created IDEMPIERE-2310 Improve description field with inline Html editor and html rendering 
'''''Not-57f0''''': [IDEMPIERE] http://idempiere.atlassian.net/browse/IDEMPIERE-2310 
'''''allgood''''': CarlosRuiz: this is a small sketch of my idea: http://pastebin.com/ULWj3H8t 
'''''allgood''''': i am pretty sure it needs a lot of work, but the concept is there 
'''''allgood''''': on adempiere, i already have a small success on making a class that gets one script with local IDs, parse it, register ID on centralized id server and outputs a script with centarilized IDs 
'''''CarlosRuiz''''': which is your goal with that? 
'''''allgood''''': making possible to get rid of centralized id 
'''''allgood''''': i think there is some problems with databases that has been migrated 
'''''allgood''''': where the uuid of the same record could be different on the generator and executor of the script 
'''''allgood''''': for that i was thinking on changing the lookup_id to lookup_id(table, uuid, name,origid) 
'''''allgood''''': then if it fails to find the uuid, falls back to name and origid 
'''''CarlosRuiz''''': scripts 791_FillUUIDPrimaryTables.sql and 793_FillUUIDChildrenTables.sql fill the UUID for official dict - so if there are problems with migrated dbs maybe is that they didn't apply correctly those scripts 
'''''allgood''''': oh, great 
'''''allgood''''': anyway the fallback could be useful 
'''''smartjsp''''': quick question have you guys checked this bug report: https://idempiere.atlassian.net/browse/IDEMPIERE-2302 we found it recently it affects both Idempiere &Adempiere 3.6.1,, just want to check if our description and provided data is clear ...and double check how is the current process to fix these core bugs ...thanks 
'''''allgood''''': as i told, the idea is just a idea in its beginning 
'''''allgood''''': it is a long time I tought that UUID would free us from depending on synchronized IDs 
'''''allgood''''': but this just happens on the 2pack front, not migration/developer 
'''''CarlosRuiz''''': we talked about that with Heng Sin - the effort to change all primary keys and foreign keys to UUID is really big 
'''''allgood''''': well, my idea doesn't get to that point 
'''''CarlosRuiz''''': so, in principle we decided that centralized IDs will be still in use for official things - and 2Pack+UUID takes care to free us from central IDs allowing us to share 
'''''allgood''''': it just makes the migration script able to determine which ID is the local equivalent of a specific UUID 
'''''CarlosRuiz''''': of course - if a good solution arise to achieve that goal can be great 
'''''allgood''''': i am looking right now at the writeLogMigrationScript method... think that there is the point to write the magic code 
'''''allgood''''': I will try to research more, i am asking here if anybody knows of a showstopper on this 
'''''CarlosRuiz''''': the implication is that you can have "official" dictionary entries with different IDs in different DBs 
'''''allgood''''': basically yes, UUID gets to be the only official value. 
'''''allgood''''': i didn't get to write any code on this. On my previous adventure on ID and migration log converting I used a sql parser library 
'''''allgood''''': to mach field names 
'''''allgood''''': match 
'''''allgood''''': for now i was thinking on getting the relations directly from the AD, to fill the GENERATE_ID and LOOKUP_ID parameters on the migration script 
'''''Deepak_''''': CarlosRuiz, I tested your code committed on iDempiere-2057 and did not found any issue yet 
'''''CarlosRuiz''''': great - thanks a lot for your tests 
'''''Deepak_''''': I confirmed with hengsin that lastPO costing method is maintained, So should we add support for same too? 
'''''CarlosRuiz''''': yep 
'''''norbertbede''''': hi CarlosRuiz, Deepak 
'''''CarlosRuiz''''': Hi norbertbede 
'''''norbertbede''''': i will test my use cases next week 
'''''Deepak_''''': Hello Norbert 
'''''Deepak_''''': Thanks Norbertbede 
'''''CarlosRuiz''''': smartjsp (Pedro), I think the ticket 2302 is well described, if you can get to a possible solution and contribute it like a patch will be great 
'''''norbertbede''''': sure :) imporant tome 
'''''Deepak_''''': Carlos, I would noticed that you added all MProduct.get with constructor 
'''''Deepak_''''': There will be surely performance impact due to same as now we are loading same record many times during import process 
'''''CarlosRuiz''''': I tried to change the MCost & MCostDetail to get trx as parameter but the tests weren't good - so I played safe 
'''''Deepak_''''': I show there is only one place we need to change for import inventory flow 
'''''Deepak_''''': But there are many other places where we need to change to make costing work properly, This includes all static methods 
'''''ocurieles_DCS''''': Hi... 
'''''CarlosRuiz''''': Hi Orlando 
'''''ocurieles_DCS''''': HI @CarlosRuiz 
'''''Deepak_''''': I want to check one more thing, Is that good idea to add equinox extension point for All import process? Or can re-factor import process so some of part can be extended 
'''''Deepak_''''': Like in import inventory, Generating ASI part can work with only Batch and Serial, Do not support for custom Attribute 
'''''Deepak_''''': So we need to clone this process if we want to customize that 
'''''CarlosRuiz''''': there are three model validator extension points on ImportProduct 
'''''CarlosRuiz''''': and ImportBPartner 
'''''CarlosRuiz''''': the idea was to add the same three extension points for all importers - but nobody have done that job 
'''''norbertbede''''': its little technical to me, but one note on Deepak idea 
'''''norbertbede''''': we have implement a field which can be parsed and able to identify custom attributes 
'''''norbertbede''''': means @attr:valu5@,@attr2:valu1@…etc 
'''''CarlosRuiz''''': the other pending thing that can be very useful would be to implement ASI import in CSV importer 
'''''norbertbede''''': the syntax is defined. not the same just abstraction layer 
'''''norbertbede''''': so we can import lots with any custom attribute 
'''''Deepak_''''': norbert, understood 
'''''norbertbede''''': jsut not time to contribute :( 
'''''Deepak_''''': But some time we need finer control on how ASI created based on some conditions 
'''''norbertbede''''': we use this when cipherlab scanners generates coma separated files with datas like guar. date, man. date, vendor, invoice no etc. 
'''''norbertbede''''': qtyinbox,layers, pallets etc. 
'''''norbertbede''''': not specific calculations 
'''''norbertbede''''': need to leave now for 1 hour.. 
'''''red1''''': hi ngordon7000 :D 
'''''Deepak_''''': Carlos, Then we will commit model validator for inventory import 
'''''Deepak_''''': I am wondering is modelValidator are good idea for import features. As model validator loaded at server start and stays in memory. Import process are used during setup of new system mostly, so unnecessary memory consumption 
'''''Deepak_''''': Thinking may extension are good alternative as those are loaded when required 
'''''CarlosRuiz''''': importers are processes - you can extend them actually 
'''''Deepak_''''': Yes 
'''''ngordon7000''''': hi red1 :) 
'''''Deepak_''''': Just check, Validator can be implemented using OSGI service 
'''''smartjsp''''': Carlos, just to double check if we find a good fix for the previous bug mentioned, how should we publish that code, as part of the jira ticket as well ?... or do the team has any other repository to integrate these high priority fixes/contributions to the core ... 
'''''hieplq''''': hi @smartjsp just create a ticket and attach your code. carlos will review before integrate 
'''''Not-57f0''''': [IDEMPIERE] carlosruiz_globalqss updated IDEMPIERE-2309 
'''''Not-57f0''''': [IDEMPIERE] Thanks [~norbert.bede], in fact what we want is to change the image, [~hengsin] suggested if there are not good options available then we can use this one: http://wiki.idempiere.org/w-en/images/b/bc/Lager_NortheastIndiana.png But I think somebody can lead us to a good PNG free-licensed image that deserves to be our homepage. The other thing that people didn't like from the homepage is the link to the webui - it's embedded into the image a 
'''''Not-57f0''''': [IDEMPIERE] http://idempiere.atlassian.net/browse/IDEMPIERE-2309 
'''''red1''''': ngordon7000: i sent you email and in private message 
'''''Not-57f0''''': [IDEMPIERE] carlosruiz_globalqss updated IDEMPIERE-2274 
'''''Not-57f0''''': [IDEMPIERE] [~tsvikruha], I think that was done by design from JJ times and maybe that's the reason for the process "Workflow to Client". The issue I see is that changing the approach you cannot have a workflow that JUST applies for System, any System workflow will apply to all clients. 
'''''Not-57f0''''': [IDEMPIERE] http://idempiere.atlassian.net/browse/IDEMPIERE-2274 
'''''ngordon7000''''': red1: thanks, got your message. 
'''''Not-57f0''''': [IDEMPIERE] hieplq created IDEMPIERE-2311 bad behavior of info window when after select a record and push enter key 
'''''Not-57f0''''': [IDEMPIERE] http://idempiere.atlassian.net/browse/IDEMPIERE-2311 
'''''Not-57f0''''': [IDEMPIERE] hieplq updated IDEMPIERE-2311 
'''''Not-57f0''''': [IDEMPIERE] my opinion is: this behavior (close infowindow) just when at dialog mode and not focus at parameter field 
'''''Not-57f0''''': [IDEMPIERE] http://idempiere.atlassian.net/browse/IDEMPIERE-2311 
'''''hieplq''''': hi mr @CarlosRuiz. please help me confirm IDEMPIERE-2311. and make new value for "Affects Version/s" 
'''''CarlosRuiz''''': hieplq, is it reproducible i.e. with info product - or info BP? 
'''''hieplq''''': with every info window 
'''''hieplq''''': this code is for info window in dialog mode. 
'''''CarlosRuiz''''': ah yes - I see 
'''''CarlosRuiz''''': ENTER closes the window 
'''''CarlosRuiz''''': wrong behavior in this case 
'''''hieplq''''': but i think, ever dialog mode, when focus in parameter field. not need close dialog 
'''''CarlosRuiz''''': probably I introduced that here -> https://bitbucket.org/idempiere/idempiere/commits/7243df8 
'''''hieplq''''': user maybe wish search with other value 
'''''hieplq''''': or check in case has change value at parameter => requery. not change => close dialog 
'''''CarlosRuiz''''': agree - if we can avoid closing on ENTER on a search parameter will be good too 
'''''hieplq''''': i remeber at a prev issue i have save parameter each time query. just add code to detect has modify or not 
'''''Not-57f0''''': [IDEMPIERE] carlosruiz_globalqss updated IDEMPIERE-2296 
'''''Not-57f0''''': [IDEMPIERE] Reviewing this behavior, it seems it has been like this since compiere times - so I agree [~hieplq] has a point here. Maybe this can have unexpected consequences and we need to check issues better - or make it configurable. 
'''''Not-57f0''''': [IDEMPIERE] http://idempiere.atlassian.net/browse/IDEMPIERE-2296 
'''''hieplq''''': hi @CarlosRuiz, i don't re-test but maybe IDEMPIERE-1867 relate behavior cache 1000 record of info window. maybe it's by design for swing is apply for web 
'''''CarlosRuiz''''': have you tried limiting the search records per role? 
'''''norbertbede''''': CarlosRuiz hieplq i would be glad if you can commit info window tickets. there was lot changes patch on patch :) exactly works we are running in our production. so believe they are stable 
'''''Not-57f0''''': [IDEMPIERE] norbert.bede updated IDEMPIERE-2296 
'''''Not-57f0''''': [IDEMPIERE] We found one consequence with [~tsvikruha], definitively we need yours help to resolve it. [~tsvikruha] please introduce last status/experiences with this patch/issue. 
'''''Not-57f0''''': [IDEMPIERE] http://idempiere.atlassian.net/browse/IDEMPIERE-2296 
'''''CarlosRuiz''''': norbertbede, I plan to do that after zk7 stabilization - to commit those on r3 
'''''norbertbede''''': ok. i see. any deadline with ZK7 apply to 2,1 ? 
'''''hieplq''''': @CarlosRuiz, just recheck when drop line. limiting the search records just apply for standard window 
'''''CarlosRuiz''''': I think hengsin integrated something to limit search records also in info window - based on role 
'''''hieplq''''': maybe you mean number of record per page. 
'''''hieplq''''': @norbertbede. can retest IDEMPIERE-1867 with my suggrest to check? 
'''''norbertbede''''': i see, i met meanwhile, CarlosRuiz mentioned record limit 
'''''norbertbede''''': i dont know tomas setup this or not, we can test it. 
'''''norbertbede''''': then just the question is pagination is valid requst for info window tab ? 
'''''CarlosRuiz''''': ah no - sorry - not per role - MaxQueryRecords is per info window 
'''''hieplq''''': @norbertbede. just change 1000 at info window class to 100 and retest. 
'''''norbertbede''''': you mean enter 100 to MaxQueryRecords field in info window 
'''''hieplq''''': no. have hard value in code 
'''''hieplq''''': must change direct code 
'''''CarlosRuiz''''': I'm going out for a couple of hours - will work again on this in my after noon - c u later 
'''''hieplq''''': line in infopanel class: m_useDatabasePaging = (m_count > 1000); 
'''''hieplq''''': bb CarlosRuiz 
'''''norbertbede''''': bye calrosruiz 
'''''norbertbede''''': just the question is why MaxQueryRecords not resolve this 
'''''norbertbede''''': not understand exactly but i can todo tomas with this 
'''''norbertbede''''': and we can review it 
'''''norbertbede''''': anyway thanks for hint 
'''''hieplq''''': MaxQueryRecords is for standard window 
'''''norbertbede''''': i see 
'''''norbertbede''''': carlosruiz mention the follow ticket 
'''''norbertbede''''': https://idempiere.atlassian.net/browse/IDEMPIERE-1954 
'''''norbertbede''''': from hengsin 
'''''hieplq''''': it's good but make other limit. you must choose, limit user to get performance or make him free and loss performance 
'''''norbertbede''''': i would prefer ad1. make pagination for info window per client/user 
'''''norbertbede''''': ability limit by hengsin approach. altogh not a useful way 
'''''norbertbede''''': ad3. implement pagination as i caht with xolali 
'''''norbertbede''''': in mentioned ticket 
'''''norbertbede''''': each ms in client patience make sense :) 
'''''norbertbede''''': i need to leave for 1 hour too 
'''''hieplq''''': ok. bb 
'''''norbertbede''''': going to dance school with my small lady :) 
'''''hieplq''''': yes. children is first 
'''''Not-57f0''''': [IDEMPIERE] tsvikruha updated IDEMPIERE-2274 
'''''Not-57f0''''': [IDEMPIERE] Document Process workflows supports this approch (when system workflow can be executed in client, thats the reason why there is a field Data Access Level) e.g. "Process_Order". But Document Value workflow is working only when it ist set on specific Client. So use case when Document Value WF is set on System, and executed on other Clients doesnt work. Now user has to set same workflow on each client separately (only Document Value WF). Thi 
'''''Not-57f0''''': [IDEMPIERE] http://idempiere.atlassian.net/browse/IDEMPIERE-2274 
'''''Not-57f0''''': [IDEMPIERE] tsvikruha updated IDEMPIERE-2296 
'''''Not-57f0''''': [IDEMPIERE] [~norbert.bede] I will try explain it. Pleas let me know if it is undestenable and correct :) [~carlosruiz_globalqss] you´re right that change like this can have unexpected consequences. We tried to change it from order A to order B. A: 1.Default logic of field 2. User Preference 3. System Preference B: 1.User Preference 2. System Preference 3. Default logic of field This change resulted in unexpected values in Organization field on Orde 
'''''Not-57f0''''': [IDEMPIERE] http://idempiere.atlassian.net/browse/IDEMPIERE-2296 
'''''efekto2k''''': hello, is anybody there? 
'''''posde''''': efekto2k, why don't you ask your real question, and wait an hour or two for replies. 
'''''efekto2k''''': it's ok. My real question is: I contact from openxpertya project (Spain), We are interested in migrate entire project to idempiere. As you can imagine, after 10 years, we have much functionality (just for swing client) that we would like to integrate and share with community. After giving a try to idempiere, we think we are ready to make it. But, we have a lot of questions about how. 
'''''hieplq''''': with a lot question, maybe you should read something at wiki, some thing at prev meeting record. 
'''''hieplq''''': and maybe post your question at google group 
'''''efekto2k''''': They are not technically questions 
'''''efekto2k''''': thank you for reply and apologize my poor english 
'''''hieplq''''': me too :D 
'''''efekto2k''''': i think we had read entire wiki, we already made some plugins and fragments 
'''''hieplq''''': any question you can ask in google group not just technically 
'''''efekto2k''''': Ok, this is the right place, right? 
'''''hieplq''''': yes. at there you also can ask. but maybe who can answer not online 
'''''hieplq''''': because i think group is best place. 
'''''hieplq''''': at there for quick and lucky :D 
'''''efekto2k''''': Ok. Thanks. I will do it for sure. 
'''''hieplq''''': why not try. please ask your question 
'''''hieplq''''': at there first. 
'''''efekto2k''''': Yes, i will ask in google group 
'''''efekto2k''''': thank you 
'''''hieplq''''': i mean you still can ask here. but google group is best for other can answer and reference 
'''''efekto2k''''': ah, ok. Well, our first questions are about community feedback about migration 
'''''hieplq''''': you mean you encounter some issue when migrate from your system? 
'''''hieplq''''': and you ask for place to report issue? 
'''''efekto2k''''': No, as i told you is not technical, it's project itself... (You know we will have a project with another name, and now we would like to based it on idempiere, so i would like to ask community wich will be the way to do it as better as we can... because we would like to continue with same name) 
'''''hieplq''''': your project is base in compiere? 
'''''efekto2k''''': yes 
'''''efekto2k''''': in 2005.... we started openxpertya 
'''''hieplq''''': i don't has experience with it. but in forum i just see everyone migrate from adempiere 3.6 to idempiere. maybe you try step by step. move your project to adempiere fisrt. 
'''''hieplq''''': or ask carlor, your company provide this service 
'''''efekto2k''''': we don't need the service, as i told you before, we already had migrated some functionality 
'''''efekto2k''''': it's project level, my question 
'''''posde''''': efekto2k, you want to know if it is okay to move to idempiere, but keep your current project name openxpertya 
'''''efekto2k''''': that's right 
'''''posde''''': i.e. it is more a legal issue you want to solve. 
'''''efekto2k''''': right 
'''''mand1nga''''': openxpertya was based on compiere or adempiere? 
'''''efekto2k''''': on compiere 
'''''efekto2k''''': orginally on compiere 
'''''posde''''': efekto2k, I can read people, but unfortunately, I do not have an answer for you. I am not sure under what license idempiere is, but I can't recall any specific OSS license which would deny anyone to rename a project. 
'''''hieplq''''': @efekto2k congres you lucky when meet people can understand you :D 
'''''efekto2k''''': xpertya, to be exactly 
'''''mand1nga''''': I think this might be a similar situation, it depends on the potential differences between compiere and idempiere licenses 
'''''hieplq''''': idempiere is follow GPL v2. because just study GPL v2 for this 
'''''mand1nga''''': still, honest question, what's the point in renaming it? 
'''''efekto2k''''': Well, 10 years of selling this product... 
'''''mand1nga''''': it's crystal clear to me that less fragmentation is better 
'''''posde''''': mand1nga, probably if you have a shitload of people that know your product/name, you don't want to change it. 
'''''efekto2k''''': that's right 
'''''efekto2k''''': we don't care to put anywhere based on idempiere 
'''''mand1nga''''': point taken 
'''''efekto2k''''': or whatever 
'''''mand1nga''''': the *open* prefix confused me a bit 
'''''mand1nga''''': in your place I'd compare the two licenses 
'''''posde''''': mand1nga, everything with open in its name sounds much better for a lot of people. 
'''''mand1nga''''': idempiere's vs compiere's 
'''''efekto2k''''': ok. But more than a legal question, just want feedback for community. I mean, even if we can do it, we won't do it if community is not agree... 
'''''mand1nga''''': posde: couldn't agree more, it's a perfect marketing stunt ;) 
'''''posde''''': :) 
'''''mand1nga''''': efekto2k: as long as you contribute changes back to idempiere it'd be hard not to support you 
'''''efekto2k''''': well, in our case, xpertya seems like "Expertis" a propietary ERP from Spain and we had to change our name for their inquire... 
'''''efekto2k''''': to openxpertya... 
'''''mand1nga''''': idempiere is already translated to spanish 
'''''mand1nga''''': you could work on a spaniard localization 
'''''efekto2k''''': well... not indeed... to Colombian, right? We didn't find Spanish Translation (For Spain).... 
'''''efekto2k''''': We are on it... 
'''''mand1nga''''': that's pretty cool 
'''''efekto2k''''': In a couple of days we will have it 
'''''mand1nga''''': we plan to start working on an argentinian one pretty soon 
'''''mand1nga''''': that's good news 
'''''efekto2k''''': Well openxpertya, has an argentinan fork called libertya... 
'''''mand1nga''''': and here you are, on the iDempiere channel ;) 
'''''efekto2k''''': We have all argentina location for openxpertya, so, it's compatible with adempiere and we can make idempiere's plugins... 
'''''mand1nga''''': imho the way to go is to stick with bigger projects 
'''''mand1nga''''': that's why oxp and libertya are way behind from idempiere 
'''''efekto2k''''': We are agree with that 
'''''mand1nga''''': from a technical perspective 
'''''mand1nga''''': if you want to work on an argeninean localization please let me know 
'''''mand1nga''''': we're about to start working on that pretty soon 
'''''efekto2k''''': How about swing client?, i mean, 80% of our modules and developments are for swing client 
'''''mand1nga''''': it's going to be a long term project for us 
'''''efekto2k''''': Yes, we are interested, and as i told you we have a lot of things done 
'''''efekto2k''''': taxes, translations, oficial printers, and so on... 
'''''mand1nga''''': I'd say you have about 20% or less is specific to swing, unless I'm terribly mistaken 
'''''mand1nga''''': that's why the Libertya crew could port and make use of the ZK UI 
'''''mand1nga''''': borrowed from Adempiere afaik 
'''''mand1nga''''': but yes, that's a thing to be worried about 
'''''mand1nga''''': the native swing interfaces such as POS/TPV 
'''''efekto2k''''': ok. Well, we will keep in touch with you... It's late here. Thank you and we will continue our conversation, if you wish. We will send google group messages, as you told us and we will study best way to do it... Thank you very much for your attention. 
'''''mand1nga''''': anytime 
'''''mand1nga''''': I've PM'd you my skype ID 
'''''mand1nga''''': cheers! 
'''''efekto2k''''': my skype id is efekto2k 
'''''efekto2k''''': so, we can contact in any moment. We will study all our developments for argentinian localization and i will inform you 
'''''hieplq''''': about swing. maybe you will like it. http://wiki.idempiere.org/en/Swing_Maintenance_Team 
'''''mand1nga''''': sounds great 
'''''hieplq''''': but this team is very lazy :D 
'''''mand1nga''''': geez there's a whole lot to do 
'''''mand1nga''''': can someone please recommend some good resources for learning swing? 
'''''mand1nga''''': I feel I need to read some books in order to reach decent productivity 
'''''CarlosRuiz''''': interesting - so iDempiere gravity is attracting fork satellites :-) 
'''''posde''''': the more the better 
'''''mand1nga''''': I've always seen it as a matter of time ;) 
'''''Not-57f0''''': [IDEMPIERE] hieplq updated IDEMPIERE-2311 labels set to "+Patch" -Attachment set to "IDEMPIERE-2311.patch" 
'''''Not-57f0''''': [IDEMPIERE] fix: I. in dialog mode, after select a record in result list. 1. focus to a parameter field, push enter => close dialog as normal 2. edit value of any parameter field, push enter => re-query result. II. in window mode. never close window when push enter with focus at any parameter field in any condition. 
'''''Not-57f0''''': [IDEMPIERE] http://idempiere.atlassian.net/browse/IDEMPIERE-2311 
'''''Not-57f0''''': [IDEMPIERE] hieplq updated IDEMPIERE-2311 status set to "Peer Review Queue" 
'''''Not-57f0''''': [IDEMPIERE] http://idempiere.atlassian.net/browse/IDEMPIERE-2311 
'''''hieplq''''': Hi mr @CarlosRuiz. just inform i fix IDEMPIERE-2311. please help me review it. 
'''''CarlosRuiz''''': thanks hi 
'''''Not-57f0''''': [iDempiere] CarlosRuiz_globalqss pushed 1 commit to release-2.1 [+0/-0/±1] https://bitbucket.org/idempiere/idempiere/commits/ 
'''''Not-57f0''''': [iDempiere] globalqss 94ddfdf - IDEMPIERE-2311 bad behavior of info window when after select a record and push enter key / IDEMPIERE-2112 
'''''Not-57f0''''': [IDEMPIERE] carlosruiz_globalqss updated IDEMPIERE-2311 
'''''Not-57f0''''': [IDEMPIERE] Thanks [~hieplq], I committed a solution for the issue with http://bitbucket.org/idempiere/idempiere/commits/94ddfdf Your solution seems more robust - but in my tests it didn't achieve the goal - it was always executing the query even if the parameters didn't change. 
'''''Not-57f0''''': [IDEMPIERE] http://idempiere.atlassian.net/browse/IDEMPIERE-2311

@@ Line 17: / Line 17: @@
 '''''allgood''''': yes<br>
 '''''allgood''''': but that is not the main idea<br>
 '''''allgood''''': CarlosRuiz: this is a small sketch of my idea: http://pastebin.com/ULWj3H8t<br>
 '''''allgood''''': i am pretty sure it needs a lot of work, but the concept is there<br>
@@ Line 96: / Line 94: @@
 '''''smartjsp''''': Carlos, just to double check if we find a good fix for the previous bug mentioned, how should we publish that code, as part of the jira ticket as well  ?... or do the team has any other repository to integrate these high priority fixes/contributions to the core ...<br>
 '''''hieplq''''': hi @smartjsp just create a ticket and attach your code. carlos will review before integrate<br>
 '''''red1''''': ngordon7000: i sent you email and in private message<br>
 '''''ngordon7000''''': red1: thanks, got your message.<br>
 '''''hieplq''''': hi mr @CarlosRuiz. please help me confirm IDEMPIERE-2311. and make new value for "Affects Version/s"<br>
 '''''CarlosRuiz''''': hieplq, is it reproducible i.e. with info product - or info BP?<br>
@@ Line 122: / Line 109: @@
 '''''CarlosRuiz''''': agree - if we can avoid closing on ENTER on a search parameter will be good too<br>
 '''''hieplq''''': i remeber at a prev issue i have save parameter each time query. just add code to detect has modify or not<br>
 '''''hieplq''''': hi @CarlosRuiz, i don't re-test but maybe IDEMPIERE-1867 relate behavior cache 1000 record of info window. maybe it's by design for swing is apply for web<br>
 '''''CarlosRuiz''''': have you tried limiting the search records per role?<br>
 '''''norbertbede''''': CarlosRuiz hieplq i would be glad if you can commit info window tickets. there was lot changes patch on patch :) exactly works we are running in our production. so believe they are stable<br>
 '''''CarlosRuiz''''': norbertbede, I plan to do that after zk7 stabilization - to commit those on r3<br>
 '''''norbertbede''''': ok. i see. any deadline with ZK7 apply to 2,1 ?<br>
@@ Line 168: / Line 149: @@
 '''''norbertbede''''': going to dance school with my small lady :)<br>
 '''''hieplq''''': yes. children is first<br>
 '''''efekto2k''''': hello, is anybody there?<br>
 '''''posde''''': efekto2k, why don't you ask your real question, and wait an hour or two for replies.<br>
@@ Line 276: / Line 251: @@
 '''''posde''''': the more the better<br>
 '''''mand1nga''''': I've always seen it as a matter of time ;)<br>
 '''''hieplq''''': Hi mr @CarlosRuiz. just inform i fix IDEMPIERE-2311. please help me review it.<br>
 '''''CarlosRuiz''''': thanks hi<br>