IDempiere/FullMeeting20120418

⇐ Table of Contents | Full Meeting Minutes | Full Meeting 2012-04-18

CarlosRuiz: Good morning
egonzalez_ergio: Good morning
mzuniga_ergio: Good morning Carlos
a42niem: hi Carlos
Nicolas_: Hi
CarlosRuiz: as usual - open agenda - I have today interesting pull requests to peer review - so I'll be working on parallel on pull requests :-)
smartjsp: Good morning everyone ....
smartjsp: question: regarging packotu and packin ... in adempiere we use to have issues when we want to export/import information and traslations ....
smartjsp: my understading is that something new is coming with idempiere ... but also want to know how you guys tranport yoru reports, menus and so on among yoru dev/test and prod environments ....
smartjsp: BTW This is Pedro Rozo ..:)
CarlosRuiz: Hi Pedro, yes, 2pack was completely rewritten by Heng Sin
CarlosRuiz: I'm not sure if it move translations, but for sure it moves menus, reports, window, tables, etc ..... - practically all dictionary entries
smartjsp: Good. Could hensing confirn the scope of the new fucntionality, and if that will be available just with idempeire, or if we will have any previous release(extension) for the current adempiere transition ?
CarlosRuiz: I don't have plans to port it that to transition version - just for idempiere
smartjsp: Coudl your guys share what is your current confidence of the existent 2pack tool about it.. I mean to transport menus, tables, reports with traslations ? do you really use 2pack for it ? for us ti dodnñt really work much ... but want to now about your previous or current experience.
CarlosRuiz: I use current 2pack for basic things - to deploy things to a customer - or transport between developers and testers
CarlosRuiz: and it always requires additional extra work
Nicolas_: i do not use 2Pack very often ; only when there are lots of thing to recreate ; i'd prefer to create manually to avoid bad surprises
CarlosRuiz: to update the columns not covered by 2pack
a42niem: i had always problems with it because obviously it tries to find the correct matching element via the name which is often ambiguous in the geram translation
a42niem: german
CIA-126: iDempiere: globalqss * dad0f9c7e8cf r7147 /org.adempiere.ui.zk/WEB-INF/src/org/adempiere/webui/component/WListItemRenderer.java: IDEMPIERE-233 Minitable implementation on zk doesn't manage editable timestamp properly
CarlosRuiz: Nicolas_ AYT?
Nicolas_: Yep
CarlosRuiz: you just wrote on IDEMPIERE-239 - "Can you please review ?"
CarlosRuiz: but I don't see attachment or link
Nicolas_: :-/
Nicolas_: i have updated it, it is better ?
CarlosRuiz: no - I don't see changes on the ticket
Nicolas_: you didnt' receive a notification for a pull request ?
CarlosRuiz: ah .... checking
CarlosRuiz: ah fine - it has mixed 236 and 239
Nicolas_: yep, i've made a mistaeke i think
CarlosRuiz: no problem - I see you did the change - we can integrate it
Nicolas_: is it possible to have more than one current request ?
CarlosRuiz: don't know :-(
Nicolas_: my first intention was to create one for IDEMPIERE 239, and a second for 236
CarlosRuiz: for 239 I think it is better to create an isActive method in Doc.java
CarlosRuiz: similar to what getC_BPartner_ID is done
CarlosRuiz: to avoid SQL errors if the column does not exist, and it avoids a visit to database using the doc in memory
CarlosRuiz: easier than getC_BPartner_ID :-) PO has already the method isActive
Nicolas_: so a if (!IsActive) return "Imposible ...." would enough ?
CarlosRuiz: yes - something like:
CarlosRuiz: if (! p_po.isActive())
CarlosRuiz: return "Cannot post inactive document";
Nicolas_: great !
CarlosRuiz: can you make that change and add it to the pull request ?
Nicolas_: i'm testing it :-)
Nicolas_: will put request in the next minute
CarlosRuiz: excellent
CarlosRuiz: about your question changing view or just SQLWhere on tab :-) good question - I think is easier to change the SQL Where
CarlosRuiz: but it also require changing DPActivities.getUnprocessedCount*(
Nicolas_: why DPActivities.getUnprocessedCount don't use the same view ?
CarlosRuiz: the idea is to restrict RV_Unposted and RV_Unprocessed
CarlosRuiz: to not show/count inactive records
Nicolas_: ah ok ; if we modify views in the database, we don't have to change DPActivities.getUnprocessedCount ; otherwise, we will have to
CarlosRuiz: exactly
buildmaster: Project iDempiere build #169: SUCCESS in 22 min: http://jenkins.idempiere.com/job/iDempiere/169/
buildmaster: globalqss: IDEMPIERE-233 Minitable implementation on zk doesn't manage editable timestamp properly
Nicolas_: sent you another pull request (idempiere 239)
CarlosRuiz: thanks - pulled
Nicolas_: Thanks !
CarlosRuiz: about expand menu - it sounds like an easy change - if you are ok I can do it
Nicolas_: no problem
CIA-126: iDempiere: nmicoud * 66ce467b8673 r7150 / (3 files in 3 dirs): IDEMPIERE-236 Centralization of hardcoded IDs / using naming convention for constants
CIA-126: iDempiere: nmicoud * 4cf161dc11e2 r7151 /org.adempiere.base/src/org/compiere/acct/Doc.java: IDEMPIERE-239 - smart way ; using IsActive() instead of SQL
CIA-126: iDempiere: nmicoud * f6b72b80e1b6 r7149 /org.adempiere.base/src/org/compiere/acct/Doc.java: IDEMPIERE-239
CIA-126: iDempiere: nmicoud * 8fbcd374f9c2 r7148 / (3 files in 3 dirs): IDEMPIERE-236 Centralization of hardcoded IDs
hengsin: hi Nicolas
Nicolas_: hi
hengsin: hi, is nmicoud, IDEMPIERE-236 = Nicolas_ ?
Nicolas_: yes
hengsin: hi, I've some comments for that. 1) Java convention usually use all uppercase with underscore as word separator for public constant
Nicolas_: Carlos already said that, i've uploaded modifications
CarlosRuiz: yep - fixed in next commit
hengsin: and should use the keyword final too ( for performance ). so for e.g "public static final int REFERENCE_POSTING_TYPE= 125;
CarlosRuiz: yep - fixed too
CarlosRuiz: great we're i sync
hengsin: 2) it is more common practise to use interface intead of class for constant declaration. make it obvious that it is not for extend and any class can use it easyly through implement.
hengsin: 3) Finally I guess SystemIDs or OfficialIDs probably sounds better and more obvious than the name "HardCodedIDs".
CarlosRuiz: Heng Sin - about 2) - the plan in future is to review if the constants can be changed by a MSysConfig.get
CarlosRuiz: ah - it's the same - it can be done with interface also
CarlosRuiz: agree with both suggestions
Nicolas_: no problem for me, i'm not a java specialist, so i do what you think is better
Nicolas_: what is the next step ? i make modification in my fork or Carlos do it directly ?
CarlosRuiz: you can do a merge on your fork - do the change and try another pull request
CarlosRuiz: sorry - first a pull on your fork - to sync it
CIA-126: iDempiere: globalqss * e4e1567cd866 r7152 /org.adempiere.base/src/org/compiere/model/MCost.java:
CIA-126: iDempiere: IDEMPIERE-241 Unnecessary cost records added on product creation
CIA-126: iDempiere: Code integrated from Compiere community 3.3.0 version
Nicolas_: ok, what would be the name ? SystemIDs, OfficialsIDs or do we keep HardCodedIDs ?
CarlosRuiz: SystemIDs sounds good for me
Nicolas_: ok
buildmaster: Project iDempiere build #170: SUCCESS in 20 min: http://jenkins.idempiere.com/job/iDempiere/170/
buildmaster: * nmicoud: IDEMPIERE-239 - smart way ; using IsActive() instead of SQL
buildmaster: * nmicoud: IDEMPIERE-236 Centralization of hardcoded IDs / using naming convention for constants
buildmaster: * nmicoud: IDEMPIERE-239
buildmaster: * nmicoud: IDEMPIERE-236 Centralization of hardcoded IDs
hengsin: fine for me too
Nicolas_: At 17:36, it was written "<CIA-126> iDempiere: Code integrated from Compiere community 3.3.0 version" ; what is it ?
CarlosRuiz: change to MCost class to avoid generating unnecessary cost records
Nicolas_: ok
Nicolas_: i have to go, i will made modification to SystemIDs tomorrow
Nicolas_: Bye
CarlosRuiz: thanks Nicolas
CIA-126: iDempiere: globalqss * 872128e25709 r7153 / (7 files in 5 dirs):
CIA-126: iDempiere: IDEMPIERE-195 Expand menu automatically / make user preference override the role configuration
CIA-126: iDempiere: http://jira.idempiere.com/browse/IDEMPIERE-195
CarlosRuiz: thanks for the meeting - I'm going out now
hengsin: bye