IDempiere/FullMeeting20141112

⇐ Table of Contents | 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
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
red1: ngordon7000: i sent you email and in private message
ngordon7000: red1: thanks, got your message.
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
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
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
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 ;)
hieplq: Hi mr @CarlosRuiz. just inform i fix IDEMPIERE-2311. please help me review it.
CarlosRuiz: thanks hi