IDempiere/FullMeeting20140507

From WikiQSS
Revision as of 22:25, 7 May 2014 by CarlosRuiz (talk | contribs) (drop JIRA notifications from log)
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)

Table of Contents | Full Meeting Minutes | Full Meeting 2014-05-07

CarlosRuiz: Good morning
hieplq: hi CarlosRuiz. on time :)
Deepak: Good Morning
Deepak: hengsin / Carlos, Any chance to review IDEMPIERE-1770?
armenrz: Hello all
red1: Hola all.. sorry i am late
red1: Nice to see you armenrz :D
red1: Apa khabar?
armenrz: hi Red1, baik :)
red1: Out of topic, but do you know our MH370 flew around west of Sumatera?
red1: Also armen, i just finished a Sales Forecast feature for the Budget module
red1: i am trying to port it for ADempiere360 too but the migrations scripts or 2Pack cannot work back there
red1: have to rebuild the AD changes by hand
red1: Here is the link if you want to see http://red1.org/adempiere/viewtopic.php?f=45&t=1798&p=8599#p8599
CarlosRuiz: backporting to AD is a nightmare after you have seen the light with the new 2pack and OSGi :-)
red1: Only the raw tables got in the DB.. not the AD_*
red1: But its good to visit back and test how the new code still works easily
red1: It proves that OSGi has no impact on business logic
armenrz: red1, it's fantastic
red1: This idea was given by Thomas Bayen just last night here and i realised it is a great idea that is easily extended in the budget module
armenrz: yes, actually sales target works almost the same way as budget
red1: You can set a target just like a budget but using the Sales Trx arg
red1: and if so the system will not stop if excess but log it in Notice
red1: and u can allow the target to change according to months or years of performance analysis
red1: Now i need another good idea what best reporting for it
red1: I am thinking Budget line relate to FactAccts difference
red1: of same criteria
red1: So u can see how far you are from your targets and budget limits every time
armenrz: red1, I just skim to read your link...can we do something like budget reviewing...i mean usually in the mid year, they like to review and change the budget ?
armenrz: or perhaps a what-if operation ? :)
norbertbede: hi all
CarlosRuiz: Hi norbertbede
CarlosRuiz: Deepak, I have not reviewed it yet
red1: armenrz: can u give me more description?
red1: so i can figure it out
red1: u can give me some pseudo design of the type of report
red1: i think the review can go through like i said but break down for each month
red1: under each rule
red1: of how many percent they are reaching to the target or limit
red1: if u can help test i should be exporting the plugin soon
red1: the code is ready and i putting in bitbucket
CarlosRuiz: hieplq, about IDEMPIERE-1935 - which password window? the "forgot my password" link? or the "reset password" form?
CarlosRuiz: ah got it - the "forgot" link
hieplq: ok :)
Deepak: CarlosRuiz, I think hengsin picket it up.
red1: yes armenrz the Generate Budget is sort of a preiodic review
red1: Anyone remember how to launch ADempiere 361?
red1: From Eclipse source
red1: And launching the Server?
red1: Ah working
red1: and hitting modelvalidator not found
CarlosRuiz: hieplq, I applied the patch for IDEMPIERE-1935 - but still enter key is stagnated at "Processing..."
hieplq: huh. i test it ok. in local and my server
hieplq: you test with case USER_LOCKING_MAX_PASSWORD_AGE_DAY
CarlosRuiz: no, forgot my password link
CarlosRuiz: on second screen it asks for email and I entered the email and pushed enter
hieplq: forgot my password link is ok in my side
hieplq: i will retest "forgot my password" my patch is for screen "change passs"
CarlosRuiz: ok - testing that one
CarlosRuiz: seems I found is a different bug similar
hieplq: ok. let me check it
hieplq: yes. similar bug, similar solution
CarlosRuiz: ok - tested and worked - thanks hieplq
hieplq: hi CarlosRuiz, https://idempiere.atlassian.net/browse/IDEMPIERE-1540 is ok to integrate to trunk or make a plug-in?
CarlosRuiz: I think that must be trunk - is configurable anyways
hieplq: thanks, I will try implement it.
hieplq: with time zone, my case is: time in server is 7-5, time in my local is 6-5, when i make new "move inventory", default value of "move date" is 7-5, same server time.
CarlosRuiz: the demo server is in Germany UTC+1 - could you please explain me the issue with that server?
norbertbede: are we talking about this https://idempiere.atlassian.net/browse/IDEMPIERE-1933
norbertbede: hiep
hieplq: yes.
norbertbede: Carlos did you read pls the menitoned issue/improvement
hieplq: UTC+1 = GMT + 1?
CarlosRuiz: I just created an inventory move record there "test"
CarlosRuiz: the Created is shown as May 7, 2014 5:15:49 PM CEST
CarlosRuiz: which is fine - that's the time of the server
CarlosRuiz: is 10:15:40 AM here
norbertbede: im in slovakia now same timezone as in germany
norbertbede: lets say i will create a record with 05-19 now
norbertbede: how the system will know that record was created in your timezone 10.15
CarlosRuiz: as it is actually the system doesn't know - because all the times on the database are using server timezone
norbertbede: so if my friend will work in USA - wake up take a caffe he will prefer to say oh my friedn has bencreate a record 10.19 my time
norbertbede: that is what about this issue is
CarlosRuiz: is it a presentation issue?
norbertbede: i suggest in issue to implement for client/org/iser timezone
norbertbede: then we can render for each user his timezone
norbertbede: server zone +/- user zone = real timestamp in logged in user zone
norbertbede: can imagine if we will improve chatt app
norbertbede: or activity stream
norbertbede: i would be glad to implement it
norbertbede: its de-facto standard in all cloud running apps
norbertbede: dont know it is hard or nor
CarlosRuiz: my question is trying to check the complexity of the solution
norbertbede: to improve
CarlosRuiz: if is a presentation issue can be easy to fix
CarlosRuiz: but implementing timezone in database sounds big impact
norbertbede: i means it is about presentation issue.
norbertbede: no-no database is only 1 time
norbertbede: i server-or cluster
norbertbede: that prerequests some changes areund adding fields timezone to client/org/user
norbertbede: then improve all fields/layouts where we render time
norbertbede: consider user zone
norbertbede: we wrote about that with hiep. we can prepare patch
norbertbede: resp. i can manage he can make investigation in code and prepare patches
CarlosRuiz: is it really userzone necessary? I think the system can figure out the timezone of the browser easily
CarlosRuiz: and that can be helpful if you're traveling
norbertbede: browser easily ?
norbertbede: what you mena
norbertbede: mean
CarlosRuiz: nevermind - maybe is not that easy :-)
CarlosRuiz: ah yes
CarlosRuiz: sorry
CarlosRuiz: is easy
CarlosRuiz: actually the timezone is being saved on AD_Session.Description
CarlosRuiz: I mean - the client timezone
CarlosRuiz: so, it can be as google - if the user has a preference it uses the preference - otherwise it shows the browser timezone
norbertbede: good. so my concept is acceptable just would be improved by browser session behaviour
hieplq: with input and display it can easy, but report, print is other story
CarlosRuiz: well - just showing the browser timezone will be an interesting improvement
CarlosRuiz: but your idea sounds good - allow the user to set a preference
hieplq: we must input timezone to jasper
norbertbede: you mean properly view time also in jasper docs too
hieplq: yes. use push print button, pass timezone to report, report print time of local not time of server and print timezone info (ex: +7)
norbertbede: but that is same is on normal reports - its one presentation "interface"
CarlosRuiz: is that a property of the formatting of the field on jasper?
norbertbede: im not familiar with jasper, know but dont like. not enoug h experience. hiep ?
hieplq: timezone it's a auto parameter (same record_id) and resper design will take care this paramete
hieplq: he can ofset all time column with this paramete
hieplq: @nobertbede just think it as a report.
norbertbede: i doun that http://community.jaspersoft.com/questions/517926/date-field-timezone-locale-na
norbertbede: don know its enough to folow or help
norbertbede: so if it will works can we get it to base Carlos ?
hieplq: help a bit :) just time make by jasper. with column time from db, he must manual offset
norbertbede: i cant imagine it as plugin, othwerwise no reason to investigate
CarlosRuiz: yep - that sounds for core
CarlosRuiz: as usual make it configurable ( as suggested by norbertbede )
norbertbede: thanks well
norbertbede: Carlos can we discuss the last issue for me ?
norbertbede: its https://idempiere.atlassian.net/browse/IDEMPIERE-1788
norbertbede: Value preference for info window process parameters
hieplq: I see other case. in this time i deploy server at usa, date is save by usa zone. next year i move server to vietnam, difference time zone make issue.
hieplq: work-around is set timezone 2 server to same
hieplq: but it can is good when adjust all time to GMT+0
norbertbede: you can run server in USA with vietnam zone
norbertbede:
norbertbede: its question for linux time settings
norbertbede: if you are administer server from vietnam in USA then no reason to run linux with USA time
hieplq: yes. it's work-around
norbertbede: or i can imagine a process to change update all date/time fields once on migration …..that need more investiation
hieplq: @CarlosRuiz, I add new patch for "forget password" window for ticket IDEMPIERE-1935, please review it.
CarlosRuiz: ok
norbertbede: Carlos can we discuss the last issue for me ?
norbertbede: its https://idempiere.atlassian.net/browse/IDEMPIERE-1788
norbertbede: Value preference for info window process parameters
norbertbede: that looks me big help to get less erros in database
norbertbede: from normal data entry
norbertbede: i classify it as important, what you mean
norbertbede: pls
CarlosRuiz: yep
norbertbede: what you mean implement value preferences - benefit/effor
norbertbede: t
CarlosRuiz: I think there is another similar suggestion from Chuck
CarlosRuiz: yep - you already linked it
CarlosRuiz: checking complexity ....
CarlosRuiz: well - if using ad_preference we would need to add AD_Preference.AD_Process_ID
CarlosRuiz: and then it seems to be straight
CarlosRuiz: thinking in Chuck's case (IDEMPIERE-1815) it could be possible also to implement something similar with AD_Form_ID
norbertbede: i agree with that, replace all forms with info window
norbertbede: much more better approach
norbertbede: we can take some windows to convert
norbertbede: i will create list of windows to replace
norbertbede: would be this way to handle as a small project
CarlosRuiz: ah - in such case we would need AD_InfoWindow_ID there
norbertbede: ok will contact chuck to talk his ideas
norbertbede: thanks anyway