IDempiere/FullMeeting20120118

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

CarlosRuiz: Morning everybody
egonzalez_ergio: Buen dia!
Azzam: Good After Noon Carlos & every body
mzuniga_ergio: Good Morning!
tbayen: Hi CarlosRuiz, good afternoon!
a42niem: hi CarlosRuiz
a42niem: hi all
CarlosRuiz: this meeting doesn't have a specific agenda - as is our first meeting I would prefer to exploit it to solve your questions
CarlosRuiz: if any
CarlosRuiz: maybe everything is very clear and I have not noticed
Azzam: I have here some questions
CarlosRuiz: sure Azzam
Azzam: Thanks
Azzam: I am beginner to OSGI & iDempiere
Azzam: so my questions will be around this
Azzam: How can we start working & using iDempiere ?
Azzam: will idempiere be community based like Adempiere ?
tbayen: I missed a clear documentation "from zero to idempiere" too. I had problems initializing the database.
Azzam: Can we expect a release for iDempiere ?
Azzam: Or is there a roadmap for idempiere ?
CarlosRuiz: just let me know when questions are complete and I'll try to start answering
Azzam: How can I ( we ) contribute in iDempiere ?
Azzam: Last question : Can we merge other branches in idempiere like fixed assets & POS ?
Azzam: Thanks
Azzam: These are my questions
CarlosRuiz: ok - let me try
tbayen: In some weeks I will want to commit code. At the moment I work with globalqss361. Which base is stable and a good base to commit code?
CarlosRuiz: > How can we start working & using iDempiere ?
tbayen: I am complete too (for the moment).
CarlosRuiz: I saw Azzam request on red1 forums
CarlosRuiz: hengsin and dominik (banym) have published interesting tutorials about how to configure idempiere on eclipse
CarlosRuiz: but Azzam asked that he wanted the before and after parts
CarlosRuiz: so I tried to expand that in my wiki
CarlosRuiz: http://www.globalqss.com/wiki/index.php/IDempiere
CarlosRuiz: starting with prerequisites installation - and explaining the after part - how to install and run
red1: hola , halo every1
CarlosRuiz: please feel free to comment on that or request further information
CarlosRuiz: Hi red1
red1: sorry i am late… caught up in traffic
red1: bad jam in Bogota…
mzuniga_ergio: Hi Red1
CarlosRuiz: are you at the office?
red1: si si
CarlosRuiz: ah, fine
CarlosRuiz: I'm trying to answer some questions from Azzam and Thomas
Azzam: Thanks Calos I can see contents of documents
CarlosRuiz: > will idempiere be community based like Adempiere ?
CarlosRuiz: idempiere IS community based - following meritocracy
CarlosRuiz: approach
red1: Hola Javier_SETSOFTWA
Javier_SETSOFTWA: i red1
Javier_SETSOFTWA: hi red1
red1: cumo esta amigo?
CarlosRuiz: about Adempiere, I prefer not to make political statements
hengsin: carlos, the current postgresql seed in iDempiere is up to date ?
CarlosRuiz: yes hengsin
CarlosRuiz: > I missed a clear documentation "from zero to idempiere" too. I had problems initializing the database.
CarlosRuiz: precisely I saw Thomas struggling with applying the migration scripts
CarlosRuiz: so I committed an updated seed past week
CarlosRuiz: is ready now for an initial preview release
CarlosRuiz: both seeds - postgresql and oracle
red1: this is a bad room / and good room (as what Carlos told me) He said if there is no one he will work for 2 hrs on iDempiere
red1: since it is not empty… he cannot work on it
CarlosRuiz: I'm very happy with the attendance - this is community work, technical can wait
red1: but it is good.. as we have others to do that
CarlosRuiz: > Can we expect a release for iDempiere ?
CarlosRuiz: yes Azzam, we're working on it
CarlosRuiz: I tried last week and found that installers are having some problems
Azzam: Thanks Carlos
Javier_SETSOFTWA: hi everybody I have two questions.
Javier_SETSOFTWA: what is the safest path to migrate to IDempiere from ADempiere 361? When can we start to using it in a production enviroment?
CarlosRuiz: I think hengsin is working on those problems (please hengsin correct me if I'm wrong)
CarlosRuiz: so, after solved I'll try to do an initial preview release
CarlosRuiz: > Or is there a roadmap for idempiere ?
red1: as i written in OSGI_Hengsin in the .com wiki.. i found the DB instance same (at that time)
CarlosRuiz: hengsin has a proposed roadmap
CarlosRuiz: but anyways I keep repeating that you must not ask for a roadmap with dates
Azzam: I will ask any dates
CarlosRuiz: the roadmap is like a routing guide - but without committed resources we cannot put dates, ok?
Azzam: Yes
red1: about resources, myself is a resource to do my own roadmap in SF/red1 under SYSNOVA
hengsin: I guess we can start setting some time line and then what we can fit into it. for e.g, 1.0 at about 3 month from now and then another release 6/9 month after that.
CarlosRuiz: I used to call the roadmap a wishlist - but hengsin roadmap is guiding about where we want to be later - so I think is a good route guide
red1: which is QA for iDempiere under Jenkins stack
Azzam: That's enough. It is noe wsie to stick on dates in opensource projetcs
CarlosRuiz: yes, I like hengsin idea
CarlosRuiz: we can make a preview release - and take 3 months to stabilize it and release the 1.0
CarlosRuiz: > How can I ( we ) contribute in iDempiere ?
red1: so i will answer if there is questions on my area - QA, using build server of Jenkins to provide testing strategy and results
CarlosRuiz: * reporting bugs
red1: at the moment i freeze 361 of Carlos instance so that the tests development are not affected
CarlosRuiz: * bringing ideas
CarlosRuiz: * spreading the word
CarlosRuiz: * Suggesting functional specifications
tbayen: If I understand right you would recommend 361 for my production system. Does it make sense for me to do clean commits to this branch or which way of contributing makes least work for you?
Azzam: we can report to bugs
CarlosRuiz: * Contributing code for functional specifications
CarlosRuiz: * Contributing sponsorship for approved functional specifications or technical/architectural improvements
Azzam: we can suggest new functionality
hengsin: beside some bug fixes and enhancement, the other thing in my mind at this point is to streamline the 1.0 release with a reasonable integration story line and do a zk6 upgrade after 1.0
red1: I am able to test important stuff such as (1) creating of new product, pricelist, and SO thru Invoicing process
red1: with accounting consequence tracked and compared with previous results
Azzam: I can share Red1 this test
CarlosRuiz: :-) just a minute I'm trying to track the questions between lines .....
CarlosRuiz: ok, last question from Azzam
CarlosRuiz: > Last question : Can we merge other branches in idempiere like fixed assets & POS ?
CarlosRuiz: Java POS is already integrated
CarlosRuiz: Fixed Assets is pending from some fixes - there are columns with romanian names, and other things that redhuan detected
CarlosRuiz: but yes, the idea is to integrate other branches - and going deeper I think the idea is decouple some of those modules in future to ease maintenance
CarlosRuiz: Thomas question now:
CarlosRuiz: > In some weeks I will want to commit code. At the moment I work with globalqss361. Which base is stable and a good base to commit code?
CarlosRuiz: I migrated globalqss361 branch to bitbucket - so, kenai is not maintained anymore (I put a notice in kenai homepage)
CarlosRuiz: globalqss361 is "semi-public"
CarlosRuiz: I mean
aldringutierrez: hi evrybody
CarlosRuiz: Hi Aldrin
aldringutierrez: i'm aldrin gutierrez from Global qss Bogota
aldringutierrez: hi Mr Carlos
CarlosRuiz: I'm providing access to code on bitbucket globalqss361 on request
CarlosRuiz: I adviced in forums that you write me showing some karma points ;-) and you'll get access
a42niem: how do i show them? :)
tbayen: So if I can access bitbucket my contributions will go to idempiere without hassles? Thanks for the answer!
CarlosRuiz: I want to clarify that the idea is not to privatize - but to encourage contributions
collazosc: what is a karma point?
collazosc: how do we get it?
Azzam: Excuse me Carlos & Every Body : I have to go to pray . Thanks Carlos & Have a Good Day
CarlosRuiz: thanks Azzam for attending
tbayen: If you dont't know by yourfself you should think about what carlos wrote (hint: read the lines with "*")
CarlosRuiz: I'll try to publish this whole meeting and announce where
tbayen: :-)
CarlosRuiz: yes - that's the idea of karma points (a name borrowed from launchpad I think)
aldringutierrez: hi red1 now i can see you
CarlosRuiz: the idea is that your contributions give you karma points
CarlosRuiz: as we don't have a current way to measure (and I don't have the time to keep tracking)
CarlosRuiz: so I just want you to write showing one of those "*" above
CarlosRuiz: and that's all
CarlosRuiz: so, a wiki page, a blog page, a bug filed on jira, etc - would be enough to give you access to globalqss361 at bitbucket
CarlosRuiz: not a big issue I hope - as I said is just trying to encourage contributions
CarlosRuiz: Thomas asked > So if I can access bitbucket my contributions will go to idempiere without hassles? Thanks for the answer!
collazosc: ok sounds good
red1: hi aldringutierrez
CarlosRuiz: for a contribution to arrive to globalqss361 and/or idempiere - there is a peer review process
CarlosRuiz: so, if the peer review process passes, yes, it will arrive there
CarlosRuiz: if not - we'll let you know the why for you to fix it and try again
CarlosRuiz: Javier asked > what is the safest path to migrate to IDempiere from ADempiere 361? When can we start to using it in a production enviroment?
CarlosRuiz: from globalqss361 to idempiere the db migration will be easy - just applying migration scripts as always
CarlosRuiz: code migration is a different thing - we'll try to document what is needed for that
red1: am i correct to say that migration is basically the same as prior all this time?
CarlosRuiz: anyways, callouts and model validators and all the stuff we're used to is backward compatible
CarlosRuiz: just that the way of putting within the jars will probably vary
red1: just that there seems to be a forking point with 361
CarlosRuiz: red1 - yes for db migration - for code migration it can be a little different
hengsin: if you don't modify model classes (MOrder, MInvoice, etc) then it will be straightforward
red1: as the 'official 370' no longer follows it as i tried to, for example the IDGenerator class for ZK Ajax testing..
red1: and i find changes to 370 not done in the best practice manner as we like it, and thus we cannot accept changes in 370 that way
CarlosRuiz: Thomas asked > If I understand right you would recommend 361 for my production system. Does it make sense for me to do clean commits to this branch or which way of contributing makes least work for you?
CarlosRuiz: I'm using globalqss361 in several installations, and I keep fixing the problems found and reported there
Javier_SETSOFTWA: thanks for the answer.
red1: bbl
CarlosRuiz: as always - to "recommend" it for production depends on the scope of your project
CarlosRuiz: but I would say that yes - this is the only version I trust at this moment - of course this is a BIASED statement - so please don't blame me for that :-D
hengsin: at this point, 361 or idempiere 1.0 depends more on the timeline of your project.
CarlosRuiz: I would like to explain something else
CarlosRuiz: how do we want to manage the "commit permissions"
tbayen: Thanks for the answers!
CarlosRuiz: somebody asked me here where is the "community repository" (meaning where is the repository where "community" can commit)
CarlosRuiz: and that's something that we want to manage different on this project
CarlosRuiz: instead of having a trunk with permissions assigned (as we did in adempiere subversion)
CarlosRuiz: we want to have a "circles of trust" model like linux - empowered by distributed version control system (DVCS) at this moment mercurial
CarlosRuiz: mercurial is a tool to fork
CarlosRuiz: so you don't need to ask us for commit permissions
CarlosRuiz: you simply fork the project
CarlosRuiz: start making your changes - and then let us know for our peer review
hengsin: for bitbucket, you can clone globalqss361, make your changes and then send in a pull request
CarlosRuiz: via "pull requests" on bitbucket - or via publishing the patch somewhere
CarlosRuiz: exactly
tbayen: Perhaps we should document some standard procedures for beginners to do an own fork and to keep it synchronized with another "fork of trust". I would like to do this.
hengsin: it will be great if we have a gerrit like system ....
CarlosRuiz: exactly Thomas - what is expected is to have "circles of trust" - in linux that works very well to manage thousands of developers
egonzalez_ergio: Hi: I have a question about distributed version control system: Why mercurial instead GIT?
hengsin: http://confluence.atlassian.com/display/BITBUCKET/Forking+a+bitbucket+Repository
CarlosRuiz: I tried to document some baby steps here http://www.globalqss.com/wiki/index.php/IDempiere/Download_the_Code
red1: tbayen at the moment i.e. Carlos trust Hengsin… and you trust Carlos.. so that is how you work
CarlosRuiz: but is still very poor documentation
CarlosRuiz: hengsin - sorry didn't understand the term "gerrit like system"
red1: if you wish to push code to Carlos… you may not get thru because Carlos does not trust you (yet)
CarlosRuiz: Emiliano - you're entering in holy wars with such question :-D
hengsin: see this for e.g - http://review.cyanogenmod.com/#change,11848 :)
mzuniga_ergio: Sorry fot that Carlos, he is always looking for war :D
CarlosRuiz: ah, I see
tbayen: I just read about pull requests. Seems there is nothing more to document - just do it. Sorry for being stupid.
CarlosRuiz: thanks hengsin for the link - I got the idea
hengsin: gerrit is only for git though, not sure there's something equivalent for mercury ...
egonzalez_ergio: is not (ever) my intention!
CarlosRuiz: ok, to answer Emiliano
CarlosRuiz: mercurial was chosen before because it was better supported on eclipse and linux/windows/mac
CarlosRuiz: seems like situation have changed now
red1: yes tbayen .. only when you wish to push, then you have to push to those Carlos trust.. i.e. Hengsin.. or those Hengsin trust… and so on.. you can read the 'Circle of Trust by Linus"
tbayen: red1, I Carlos never has to trust me. I do a pull request, he reads it, makes a decision and uses it or not, right?
hengsin: lol, I'm actually supporter of git :)
red1: yes tbayen
CarlosRuiz: I'm not against moving to git if that's what developers prefer
CarlosRuiz: I haven't played with git - but I'm ready to learn :-)
red1: Carlos or anyone may apply own discretion whether to subject you to more review or just blind acceptance (based on high trust)
hengsin: carlos, unless we want to use gerrit, it is of not much gain otherwise - better just stay as it is.
red1: there is much disfavour from users about mercurial
hengsin: ah .. one more benefit there - buckminster only support git and svn at the moment!
red1: i prefer SVN.. but that is just me (in my own present work).. i hg pull from Carlos and Hengsin work.. so i am fine as it is
CarlosRuiz: something I read when I was doing the review is that mercurial was better than git on keeping history of moved files - not sure if that's true
tbayen: Sorry, I have an important date with my children... bye! I will read later what comes out but up to now I say thanks to you for answering my questions and giving us a good community feeling.
CarlosRuiz: thanks Thomas for attending
CarlosRuiz: and thanks for bringing red1 to Colombia :-D
red1: yes Carlos.. that may explain Mercurial's high diskspace usage!
red1: all hail tbayen :D
hengsin: sorry guy, got to go, time to sleep for my boy.
CarlosRuiz: thanks hengsin - bye
tbayen: CarlosRuiz, I never dared to ask whether this was a blessing or a curse. :-) Bye
red1: Dominik banym has cursed mercurial in front of me when i was in his office… for the huge disk size it needs to transfer thru the bandwidth.. and it takes a long time
CarlosRuiz: I don't think is a problem from mercurial - I guess a git full repository must be similar in size - is more about the adempiere big history
Javier_SETSOFTWA: I have another question for you Carlos, Are you goin to publish more patches for goblalqss 361 at sourceforge?
red1: just to continue about Jenkins QA roadmap (if there is no objecton)
red1: (if there is no further question to Carlos)
CarlosRuiz: Javier, not at sourceforge, but I'll try to do at bitbucket
red1: it will be confusing to me if i have to refer to more than one repo now at bitbucket
Javier_SETSOFTWA: ok
Javier_SETSOFTWA: thanks.
red1: (about QA at Jenkins).. i froze a 361 instance of Kenai repo until next time in future when carlos may say he is ready to release
red1: then i will update one shot from him and run the tests again.. to see if all lights are green as before
red1: if not, i will debug backwards.. going back…
red1: this is temporary measure as Jenkins QA process is not fully matured
red1: so anyone who wants to help me can contact or shout at my forums or SF / red1
Azzam: Excuse me Carlos & Every Body : I am leaving now . Have a Good day & Blessed efforts
CarlosRuiz: bye Azzam
egonzalez_ergio: bye Azzam
red1: bye Azzam
red1: once the Jenkins QA is matured (all tests are fully created and standardised or frozen themselves) then the tests will be switched to live and constantly run each time there is a commit on the target repo
red1: at the moment i got a good set of ground tests.. New Product Sales to Invoice accounting, Fixed Assets Depreciation cycle, ZK Sales process cycle
red1: JUnit All tests (from Extend folder of ADempiere)
red1: Openbravo POS JUnit testing
red1: German Localisation deployment, plus normal binary deployment of Apps server
red1: and DB drop, ImportADempiere, apply migration script, silientsetup all at one go
red1: so at the moment this is ALL green for 361 (frozen one month back)
red1: my roadmap is to create JUnit4OSGi testing to prepare that such tests must run in future for iDempiere
red1: hope to complete the framework for that in February 2012
red1: by June 2012 a matured set of tests will then go live
red1: by end 2012, almost all functionality from black box to conditional testing must be sufficient
red1: and it goes on and on as features are added.. i will try to find a way to make testing dynamic.. self generating (for 2013)
red1: good thing is that technology is on the leading edge as we speak… JUnit4OSGi is just released, so is GWT2.4 (another sub project i am doing)
red1: I been reading GWT/GAE latest videos from Google.. it seems cutting edge that they are just going beta with new RequestFactory that hopes to super hype the GWT engine speed
red1: i am telling all these hoping to 'motivate' more members to think about it for a moment (and join in)
red1: as it is lots of fun :D
red1: i also made a backup of the Jenkins configuration in a zip file so anyone can take it and replicate for themselves
red1: so no work can be lost.. and another member of the community can always reuse and improve on it
red1: Carlos, i think we explained everything quite well in the "Bogota Announcement" :D
red1: (missing a more noisy bazaar - hmm.. no more wars it seems) :D
CarlosRuiz: :-) it will be at the scream lounge
red1: Hi Edwin_Ang .. hows Jakarta?
Edwin_Ang: hi red1
CarlosRuiz: just wait for the first reversion to a noisy person and you'll have your first scream :-D
Edwin_Ang: :)
red1: I be going Jakarta i hope in March.. got too many friends i promised there.. in Bandung
red1: please organise a talk :>
Edwin_Ang: u r very welcome here
Edwin_Ang: of course we can arrange that for u
red1: hope to meet Armen Rizal
red1: i will be staying with friends in Jakarta and Bandung (very old friends)
Edwin_Ang: it's raining season right now
collazosc: red1 do you remember my yesterday question about the annoying emails sent by the system? well I still did not catch how to avoid that
red1: yes.. monsoon season...
Edwin_Ang: hopefully the weather will be nicer in March
red1: ah yes collazosc .. did u do a search in the code?
red1: let me try that for u now
red1: calling up Eclipse
red1: and also ADempiere app
collazosc: I did it but I could not catch where the server start it
red1: perhaps it is set in some window about Notices
Edwin_Ang: i would like to ask something now
Edwin_Ang: i've been working on fixed assets too lately
Edwin_Ang: i want to contribute it
red1: collazosc: in SystemConfig there is BCC email setting
Edwin_Ang: should i complete everything or i can do it in phases
red1: perhaps it can be extended from there, to have 'NO EMAILS' and modify at the same code used
red1: Edwin_Ang: it is best in phases
red1: what is needed is proper document to guide it
red1: as review is easier that way
collazosc: ok I will check and let you know
red1: (I am qualified tester having passed CTFL basic exams) which taught me that code review actually begins with the specs document
red1: so u need to write a specs document for others to read and review and check if it is in line with what is done
red1: in a way u done exactly that via your writing in the forum… (in pieces)
red1: and u got some important feedback which i read too
red1: important is that i have stabilised FA somewhat with my last QA review (which i found some my own errors)
red1: and rmoved the 3 Romanian fields elements
red1: but i kept it as package for the sake of testing packages
red1: it can easily go in anytime Carlos wants to.. but i prefer it not go in now.. as it is not urgent
red1: OR it is easily applied as my Jenkins testing is for applying that easily
Edwin_Ang: i am also preferring it as a package
red1: also i am hoping to convert that as an OSGI plugin component
red1: precisely...
Edwin_Ang: do we have a template for the specs document?
red1: so if it is in the trunk we can all get confused again
red1: Edwin_Ang: i think Adaxa has the nice format
red1: but Pedro Rosa who meets us here in Bogota also has a good format
red1: they all seems standard.. (with revision number and credits mostly)
red1: and proper numbering of specs for easy reference
red1: so i guess u might already can do one right away
Edwin_Ang: and since we don't have an idempiere release yet
Edwin_Ang: which version of adempiere should i used as based for this package
Edwin_Ang: currently most of my work is adempiere360+ globalqss patch 0709
red1: are you using source code level?
red1: or binary?
Edwin_Ang: source code
red1: ok.. i think it is safe to use latest frozen as i announced in my SF/red1 Jenkins stack
red1: i think i wrote the Revision number somewhere either there or in red1 forum on that
red1: it is safe anyway as FA does not disturb core.. other than what i commented as with MInvoice ( i think)
Javier_SETSOFTWA: bye evary one
Edwin_Ang: the code is ok
Edwin_Ang: usually the migration script is the issue
red1: perhaps the errors i discovered were due to version upgrade as my first test upgrade on FA was some time ago compared to just last month which i found some errors (come to think of it)
red1: you should use my package as base
red1: and then generate your changes as migration scripts
Edwin_Ang: i actually use your FA work as base
red1: then it can go on same base and thus we have common base
red1: good
Edwin_Ang: the code is quite stable right now
red1: so in that way u try to avoid a 'fork' if possible
red1: an then i can reuse same tests to see if you broke the base
Edwin_Ang: but i have mixed up the migration script with some customization work
red1: (i am not saying it is bad to break or fork)
red1: we merely want to identify which base is good or better
red1: i am welcoming if yours is better
Edwin_Ang: actually i am not inventing a new one
Edwin_Ang: just making Teo's code running
red1: ah so it will be good if you can separate your customization from the core improvements you done
red1: exactly.. Teo's code is not really complete
red1: :D
red1: and even break Robert Klein's
Edwin_Ang: his has a lot of Romanian local requirement i think
red1: si si
Edwin_Ang: i take them all out
red1: yes.. he asked to remove his financing fields
red1: as i reported.. hengsin agreed and so i took it out
Edwin_Ang: you can say it is a simplified FA
red1: its good that Teo still give me back his feedback on this
Edwin_Ang: add i added a little missing parts here and there
red1: that will be a good idea .. as long that it does not break what is working there
red1: wow.. that will be a big jump if you manage to push that through for our package
red1: cos no one i know really use it for production
Edwin_Ang: give me a week.. i will prepare the specs documents and migration scripts
Edwin_Ang: i not very good with documentation though.. :D but i'll try
red1: collazosc: i found the java concerned
Edwin_Ang: and i also need some help with the centralized ID
red1: collazosc: take a look under org.compiere.util.Email.java
red1: Edwin_Ang: do u have an account for that?
Edwin_Ang: nope
red1: u can (a) ask from Berlin (b) ask from CarlosRuiz
red1: your choice :D
red1: and i can teach u to use that in about 10 mins
red1: just be careful not to export your data without relogin
Edwin_Ang: i feel better here.. so may i please request for it, Carlos?
red1: Edwin_Ang: i recommend you make a request in ADempiere forum first :D
red1: i do not wish to be accused of been a Che Guevara rebel
red1: and Carlos can issue u one here also.. both ID usage do not conflict
Edwin_Ang: i am not comfortable there
Edwin_Ang: so let me ask here
Edwin_Ang: :D
red1: but i think Carlos has to give us a patch in our SystemConfig code so that it refers to the new ID mgmt
red1: OK.. wait for 7 mins :D
red1: not 7 mths
red1: collazosc: i trace that email java back to MClient java.. and so i think the solution maybe in there.. which tests for Email value.. thus.. do not give an email service and you should not get any emails :D
red1: Edwin_Ang: i will bring this up with CarlosRuiz as i am staying with him (just that i am at his office now and he is still at home!)
Edwin_Ang: oh? so you run his office now?
Edwin_Ang: :D
red1: haha.. i drop some bombs here and there :D
collazosc: yes I found Mclient.java but could not find from where it's called from.
red1: actually i followed one of his staff back home that shows me the very interesting bus system
red1: that solves the bad jams
red1: collazosc: it is not a matter of tracing further.. the code says "if you have a value"
red1: line 773: if (email == null)
red1: during setup u can give a dummy email ID
red1: unless you are really using it.. then let me look further
collazosc: oh yes I could block behavior there but my concern is that probably this will block also other wanted emails (alerts in inventory)
collazosc: so i was trying to find the place where those inactivity alert email are generated
CarlosRuiz: sorry - I'm in a meeting at skype - but maybe I can check periodically here :-)
red1: it is under SendEmail.. and it is called by different events
Edwin_Ang: inactivity alert?
CarlosRuiz: collazosc, what is the message on log that you want to stop ?
Edwin_Ang: i think it is related to request
red1: si.. then u find that calling class
red1: CarlosRuiz: Edwin_Ang is requesting for Centralised ID
collazosc: "Inactivity Alert" that fill my logs
red1: then it maybe under Notices
red1: u can set that i think in that window
CarlosRuiz: you just need to disable the GardenWorld request processor and restart the server
CarlosRuiz: I still have not setup the iDempiere Centralized ID - but I'll do
CarlosRuiz: Edwin_Ang, can you please send me an e-mail requesting that with your preferred user name and password
Edwin_Ang: send to where?
red1: Edwin_Ang: i think its best u ask in forum
red1: our peaceful forum :D
red1: so that others can reuse your request there
red1: and Carlos can manage easier
red1: as he can check that thread "Request for Centralized ID"
red1: i think u can open a thread under "Building ADempiere"
red1: is that ok CarlosRuiz ?
collazosc: carlos how do I disable the request processor (sorry for the naive question)
red1: collazosc: wait… i think there is a better way
red1: its about setting Notice preference
red1: i am looking for it
red1: Go to User window
red1: under User Contact (main tab) u find the Notification Type setting
CarlosRuiz: red1 - as the request involves a password is better private
CarlosRuiz: collazosc, enter as GardenAdmin and go to "Request Processor" window and inactivate it
red1: yes carlos i dont mean to send the password via forum
red1: i mean to make requests to u for that
red1: they can ask there and you reply with your procedure and any guide on it
Edwin_Ang: done with the forum request
red1: then others will see it is visible and make same request or remember how to ask
Edwin_Ang: please assist :D
hengsin: carlos, please setup one for me too.
CarlosRuiz: sure will do
red1: me too :>
red1: ok .. i will ask in the 'proper' way in the forum
red1: too bad we have no committee :)