IDempiere/FullMeeting20140312 - Revision history

CarlosRuiz: drop JIRA notifications from log

2014-03-13T03:57:33Z

drop JIRA notifications from log

CarlosRuiz: full meeting

2014-03-13T03:57:01Z

full meeting

New page

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


'''''CarlosRuiz''''': Good Morning 
'''''nmicoud''''': Bonjour 
'''''nmicoud''''': Carlos, could you review https://idempiere.atlassian.net/browse/IDEMPIERE-1707 today (there is a patch attached) ? i got the issue in a production environnment... 
'''''CarlosRuiz''''': ok 
'''''nmicoud''''': thanks a lot 
'''''nmicoud''''': actually, i thought it was already included in the trunk and my first guess was there was another issue :) 
'''''tbayen''''': Daarestiet! 
'''''nmicoud''''': hi Thomas 
'''''CarlosRuiz''''': saw that somebody opened the idempiere wikipedia page http://en.wikipedia.org/wiki/IDempiere 
'''''CarlosRuiz''''': same as it happened with adempiere - very quickly is asked to met the notability guidelines 
'''''CarlosRuiz''''': do you remember red1? :-) 
'''''red1_''''': Haha 
'''''red1_''''': Yes 
'''''red1_''''': Sadly we not notable to big brothers media 
'''''red1_''''': As citation 
'''''CarlosRuiz''''': I remember the notability guideline was coverage on the five continents - and yes that we have it 
'''''CarlosRuiz''''': at Krefeld conference there were four continents represented - and the fifth is represented by their big contributions 
'''''AndChat-314001''''': Readin it 
'''''CarlosRuiz''''': this graphic is also representative about coverage 
'''''CarlosRuiz''''': https://sourceforge.net/projects/idempiere/files/v2.0/stats/map?dates=2013-11-01%20to%202014-03-12 
'''''red1''''': I think myself appearing in global newspapers is notable 
'''''red1''''': and also global babes 
'''''aguerra_''''': hello everybody!!! 
'''''Not-005''''': [iDempiere] CarlosRuiz_globalqss pushed 1 commit to release-2.0 [+0/-0/±1] https://bitbucket.org/idempiere/idempiere/commits/ 
'''''Not-005''''': [iDempiere] jarboleda 7d46b76 - IDEMPIERE-1775 PackOut process is not exporting UUIDs references for fields M_Locator_ID and C_Location_ID 
'''''Not-005''''': [IDEMPIERE] carlosruiz_globalqss updated IDEMPIERE-1775 status set to "Resolved" -resolution set to "Fixed" 
'''''Not-005''''': [IDEMPIERE] http://idempiere.atlassian.net/browse/IDEMPIERE-1775 
'''''CarlosRuiz''''': Hi Alejandro 
'''''CarlosRuiz''''': nmicoud, testing IDEMPIERE-1707 
'''''nmicoud''''': ok thanks 
'''''CarlosRuiz''''': Hi ocurieles_SOSVEN 
'''''CarlosRuiz''''': I noticed your team committed an interesting patch here 
'''''CarlosRuiz''''': https://bitbucket.org/cypeberp/toc-adempiere/commits/155da73 
'''''ocurieles_SOSVEN''''': Hi @CarlosRuiz 
'''''CarlosRuiz''''': "Improvement to display sql columns in VSortTab and ADSortTab" 
'''''CarlosRuiz''''': is it ok to review and integrate? 
'''''aguerra_''''': hi ocurieles_SOSVEN 
'''''ocurieles_SOSVEN''''': sure Carlos 
'''''aguerra_''''': hi CarlosRuiz 
'''''ocurieles_SOSVEN''''': is Work of Angel Parra 
'''''ocurieles_SOSVEN''''': Hi @aguerra_ 
'''''CarlosRuiz''''': yep - I mean - seems good for core - ok if integrated? 
'''''ocurieles_SOSVEN''''': of course 
'''''ocurieles_SOSVEN''''': do it 
'''''ocurieles_SOSVEN''''': HI @red1 
'''''CarlosRuiz''''': thanks 
'''''ocurieles_SOSVEN''''': @CarlosRuiz the access to the repo is ready 
'''''CarlosRuiz''''': thanks 
'''''JanThielemann''''': CarlosRuiz, are the charts of accounting up to date? which one should i use for a new client? as far as i remember, the german ones are broken but in my case i only need the chart of accounting to create a new client 
'''''CarlosRuiz''''': AccountingUS.csv is the only one maintained up to date in trunk 
'''''JanThielemann''''': thx 
'''''tbayen''''': JanThielemann, I have an updated german version in my repository 
'''''tbayen''''': https://bitbucket.org/tbayen/smallprojects/src/tip/iDempiereAccounting/?at=default 
'''''JanThielemann''''': thank you as well 
'''''CarlosRuiz''''': nmicoud, I refactored some things on MCountry 
'''''Not-005''''': [iDempiere] CarlosRuiz_globalqss pushed 1 commit to release-2.0 [+0/-0/±1] https://bitbucket.org/idempiere/idempiere/commits/ 
'''''Not-005''''': [iDempiere] globalqss 469f514 - Fix IDEMPIERE-1707 A single default country for all tenant 
'''''CarlosRuiz''''': local tests passed - can you please test it too? 
'''''nmicoud''''': ok, will do this 
'''''Not-005''''': [IDEMPIERE] carlosruiz_globalqss updated IDEMPIERE-1707 status set to "Resolved" -resolution set to "Fixed" 
'''''Not-005''''': [IDEMPIERE] http://idempiere.atlassian.net/browse/IDEMPIERE-1707 
'''''Not-005''''': [IDEMPIERE] carlosruiz_globalqss updated IDEMPIERE-1811 
'''''Not-005''''': [IDEMPIERE] [~jan.thielemann] how is your display logic? 
'''''Not-005''''': [IDEMPIERE] http://idempiere.atlassian.net/browse/IDEMPIERE-1811 
'''''Not-005''''': [IDEMPIERE] jan.thielemann updated IDEMPIERE-1811 
'''''Not-005''''': [IDEMPIERE] @OrderType@=VE and @OrderType@=RA 
'''''Not-005''''': [IDEMPIERE] http://idempiere.atlassian.net/browse/IDEMPIERE-1811 
'''''JanThielemann''''': jira ping pong :) 
'''''CarlosRuiz''''': JanThielemann, I asked displaylogic because I was testing with the tab "POS Payment" and it works fine 
'''''CarlosRuiz''''': the tab is shown when you have a payment rule "Mixed POS Payment" and hidden for the other payment rules 
'''''JanThielemann''''': does it get hidden again once it showed up? 
'''''CarlosRuiz''''': I changed payment rule back and forth several times and every time it works fine - hiding and showing the tab 
'''''JanThielemann''''': hmm 
'''''JanThielemann''''': i use the current release-2.0 
'''''CarlosRuiz''''': but in your case you're using a context variable set on a callout 
'''''CarlosRuiz''''': is possible the callout is not being called? 
'''''CarlosRuiz''''': or not arriving to CalloutOrder line 110 for any reason? 
'''''JanThielemann''''': i'll debug, give me some minutes 
'''''JanThielemann''''': callout gets executed and correct value is written to context 
'''''CarlosRuiz''''': your display logic says "and" instead of "&" ? 
'''''JanThielemann''''': ? 
'''''JanThielemann''''': oh 
'''''JanThielemann''''': no, i have @OrderType@=VE to display tab 1-3 
'''''JanThielemann''''': and @OrderType@=RA to display 4-5 
'''''JanThielemann''''': these are my two display logics to display different tabs based on display logic 
'''''JanThielemann''''': based on order type i mean 
'''''CarlosRuiz''''': the other thing to review maybe would be if the display logic is evaluated before of after the callout 
'''''CarlosRuiz''''': a breakpoint on GridTab line 1618 approx 
'''''JanThielemann''''': this method gets never called 
'''''JanThielemann''''': after chaning the value of order type 
'''''JanThielemann''''': also not before 
'''''CarlosRuiz''''': must be in CompositeADTabbox - line 442 
'''''CarlosRuiz''''': but I noticed the issue 
'''''CarlosRuiz''''': there is an array of dependent fields 
'''''CarlosRuiz''''': on AbstractADTabbox 
'''''CarlosRuiz''''': the array is called m_dependents 
'''''CarlosRuiz''''': it has the dependent fields to verify the display logic 
'''''CarlosRuiz''''': as your variable is not a field I guess is not being called 
'''''JanThielemann''''': when i select my order type for the first time, updateTabState() gets called 
'''''JanThielemann''''': for the second time not 
'''''CarlosRuiz''''': a trick that must work is something like 
'''''CarlosRuiz''''': @OrderType@=RA & @C_DocTypeTarget_ID@=@C_DocTypeTarget_ID@ 
'''''CarlosRuiz''''': dirty trick 
'''''JanThielemann''''': yep works 
'''''Not-005''''': [IDEMPIERE] jan.thielemann updated IDEMPIERE-1811 
'''''Not-005''''': [IDEMPIERE] Workaround: @OrderType@=VE & @C_DocTypeTarget_ID@=@C_DocTypeTarget_ID@ 
'''''Not-005''''': [IDEMPIERE] http://idempiere.atlassian.net/browse/IDEMPIERE-1811 
'''''JanThielemann''''': you can close the ticket if you want 
'''''JanThielemann''''': i am satisfied with this solution 
'''''CarlosRuiz''''': maybe an annotation on DisplayLogic for tab mentioning that context variables must be fields to be evaluated would be worthy 
'''''CarlosRuiz''''': so, the ticket can be a documentation improvement 
'''''Not-005''''': [IDEMPIERE] sjeffen updated IDEMPIERE-1806 
'''''Not-005''''': [IDEMPIERE] Hi I understand the scenario for migration, but what I’m talking about is the case where the Admin by mistake deselect the Advanced Role for the admin role. Then the only method of getting the Advance role check box back in the role window is by using the sql script mentioned in the migration wiki! This is by no means very user friendly and very hard to explain why you would need a sql script in order to restore the field! /Flemming 
'''''Not-005''''': [IDEMPIERE] http://idempiere.atlassian.net/browse/IDEMPIERE-1806 
'''''Not-005''''': [IDEMPIERE] carlosruiz_globalqss updated IDEMPIERE-1806 
'''''Not-005''''': [IDEMPIERE] But if you make the field editable for normal users then the whole security measure is broken. 
'''''Not-005''''': [IDEMPIERE] http://idempiere.atlassian.net/browse/IDEMPIERE-1806 
'''''Not-005''''': [IDEMPIERE] sjeffen updated IDEMPIERE-1806 
'''''Not-005''''': [IDEMPIERE] No, you would not break the security of iDempiere as the Role window should not be accessible for the ordinary/normal user, it should only be accessible for the Administrator. The Role window is where you set up the security of the system and thus the window is not meant for the ordinary/normal user! If the user has access to the Role window, he would have access to all information for the client and then the security would be compromised! 
'''''Not-005''''': [IDEMPIERE] http://idempiere.atlassian.net/browse/IDEMPIERE-1806 
'''''Not-005''''': [IDEMPIERE] carlosruiz_globalqss updated IDEMPIERE-1806 
'''''Not-005''''': [IDEMPIERE] Flemming, that sounds like your specific implementation case - and it can be easily configured for your needs. There can be another implementation case where somebody has a role "Security Configurator" with access to the role window, but no access to advanced fields. 
'''''Not-005''''': [IDEMPIERE] http://idempiere.atlassian.net/browse/IDEMPIERE-1806 
'''''Not-005''''': [IDEMPIERE] sjeffen updated IDEMPIERE-1806 
'''''Not-005''''': [IDEMPIERE] Carlos – I’m smiling. I know it can be easily configured as I have already done that. But I would not say my scenario is an specific implementation case, rather a normal expectation of how it should work. I would say that if I have access to a field when it is checked and when it is unchecked I don’t have access to that field and in order to get it back I would have to run a sql script! This behavior is simply not logically and to sa 
'''''Not-005''''': [IDEMPIERE] http://idempiere.atlassian.net/browse/IDEMPIERE-1806 
'''''Not-005''''': [IDEMPIERE] carlosruiz_globalqss updated IDEMPIERE-1806 
'''''Not-005''''': [IDEMPIERE] Again Flemming, we're almost on the same page - just that you're looking your specific use case - and I'm looking for other use cases (i.e. the "Security Configurator" role above). I agree that your discovery is an undesirable behavior - but I disagree with your solution because I think is specific to your happening and there are other valid use cases where your solution is not the right. In this case the approach can be to warn the user a 
'''''Not-005''''': [IDEMPIERE] http://idempiere.atlassian.net/browse/IDEMPIERE-1806 
'''''Not-005''''': [IDEMPIERE] carlosruiz_globalqss updated IDEMPIERE-1670 status set to "Resolved" -assignee set to "hieplq" -resolution set to "Fixed" 
'''''Not-005''''': [IDEMPIERE] http://idempiere.atlassian.net/browse/IDEMPIERE-1670 
'''''Not-005''''': [IDEMPIERE] hieplq updated IDEMPIERE-1674 labels set to "+Patch" -Attachment set to "IDEMPIERE-1674.patch" 
'''''Not-005''''': [IDEMPIERE] fix for 3 window: cost adjust, physical inventory, internal inventory 
'''''Not-005''''': [IDEMPIERE] http://idempiere.atlassian.net/browse/IDEMPIERE-1674 
'''''Not-005''''': [IDEMPIERE] hieplq updated IDEMPIERE-1674 status set to "Peer Review Queue" 
'''''Not-005''''': [IDEMPIERE] http://idempiere.atlassian.net/browse/IDEMPIERE-1674 
'''''Not-005''''': [IDEMPIERE] sjeffen updated IDEMPIERE-1806 
'''''Not-005''''': [IDEMPIERE] I rest my case – still think this is a plain stupid user experience and that is based on my +15 year’s experience of implementing and developing ERP systems! /Flemming 
'''''Not-005''''': [IDEMPIERE] http://idempiere.atlassian.net/browse/IDEMPIERE-1806 
'''''Not-005''''': [IDEMPIERE] carlosruiz_globalqss updated IDEMPIERE-1806 
'''''Not-005''''': [IDEMPIERE] I'm sorry that you disliked my proposed solution. Anyways the great about iDempiere is that is so configurable that enables you to set up your implementation as you prefer and same for all users with other different needs. Thanks for your valuable opinion based on your vast experience. It led to a migration note that was missing, and I'm sure other users will find your configuration advice here worthy too. 
'''''Not-005''''': [IDEMPIERE] http://idempiere.atlassian.net/browse/IDEMPIERE-1806 
'''''Not-005''''': [IDEMPIERE] hieplq updated IDEMPIERE-1806 
'''''Not-005''''': [IDEMPIERE] I see it same a case in window. when admin remove all user in security tab of a folder. nobody can access, change properties, set right in this folder. it's suitable. we see “Access Advanced” field as a "Advanced" field. because when admin remove right “Access Advanced”, he can't see this field. it's also suitable. I also run sql is not friendly with user. same window, admin can re get right access folder by run a process get owner 
'''''Not-005''''': [IDEMPIERE] http://idempiere.atlassian.net/browse/IDEMPIERE-1806 
'''''Not-005''''': [IDEMPIERE] carlosruiz_globalqss updated IDEMPIERE-1806 
'''''Not-005''''': [IDEMPIERE] Hiep - do you mean http://wiki.idempiere.org/en/SQL_Process_(Form_ID-111) ? 
'''''Not-005''''': [IDEMPIERE] http://idempiere.atlassian.net/browse/IDEMPIERE-1806 
'''''Not-005''''': [IDEMPIERE] carlosruiz_globalqss updated IDEMPIERE-1806 
'''''Not-005''''': [IDEMPIERE] Hiep - do you mean [http://wiki.idempiere.org/en/SQL_Process_(Form_ID-111)] ? 
'''''Not-005''''': [IDEMPIERE] http://idempiere.atlassian.net/browse/IDEMPIERE-1806 
'''''Not-005''''': [IDEMPIERE] hieplq updated IDEMPIERE-1808 labels set to "Security" -description set to "Redo step: 1. config to use email for login 2. modify value of email and password of "garden admin" same as "superUser" 3. login with this email and password. issue 1: just user superUser is login. never select "garden admin" it's by logic in get(Properties ctx, String name) in class MUser update: it's can't guess. sometime is this user sometime is other user issue 
'''''Not-005''''': [IDEMPIERE] http://idempiere.atlassian.net/browse/IDEMPIERE-1808 
'''''Not-005''''': [IDEMPIERE] hieplq updated IDEMPIERE-1806 
'''''Not-005''''': [IDEMPIERE] SQL Process is not enough friendly. because user still remember sql command. I think about "Report & Process" or anything can run a sql. Make new class AdminProcess extends SvrProcess parameter is type. when type = Reset "Access Advanced: just do sql command to reset for only System Use after we can add more type. 
'''''Not-005''''': [IDEMPIERE] http://idempiere.atlassian.net/browse/IDEMPIERE-1806 
'''''nmicoud''''': @CarlosRuiz : hi, i've tested your patch for https://idempiere.atlassian.net/browse/IDEMPIERE-1707 and it seems ok. at least i was not able to reproduce the issue. i will patch the production instance with it 
'''''Not-005''''': [IDEMPIERE] hieplq updated IDEMPIERE-1742 labels set to "+Patch" -Attachment set to "IDEMPIERE-1742.patch" 
'''''Not-005''''': [IDEMPIERE] http://idempiere.atlassian.net/browse/IDEMPIERE-1742 
'''''Not-005''''': [IDEMPIERE] hieplq updated IDEMPIERE-1742 status set to "Peer Review Queue" 
'''''Not-005''''': [IDEMPIERE] http://idempiere.atlassian.net/browse/IDEMPIERE-1742 
'''''Not-005''''': [iDempiere] CarlosRuiz_globalqss pushed 3 commits to release-2.0 [+0/-0/±4] https://bitbucket.org/idempiere/idempiere/commits/ 
'''''Not-005''''': [iDempiere] hieplq cba8cc0 - IDEMPIERE-1670:log-in with ldap account fail 
'''''Not-005''''': [iDempiere] globalqss 26941a4 - IDEMPIERE-604 Fix implementation hiding SQL errors from user - all SQL errors are being shown as "timeout error" 
'''''Not-005''''': [iDempiere] globalqss 5f2b43f - IDEMPIERE-1536 Error running a report with SQL columns / thanks to Antonio Cañaveral for suggested patch 
'''''Not-005''''': [IDEMPIERE] carlosruiz_globalqss updated IDEMPIERE-1536 status set to "Resolved" -assignee set to "Carlos Antonio Ruiz Gomez" -resolution set to "Fixed" 
'''''Not-005''''': [IDEMPIERE] http://idempiere.atlassian.net/browse/IDEMPIERE-1536 
'''''CarlosRuiz''''': thanks nmicoud

@@ Line 30: / Line 30: @@
 '''''red1''''': and also global babes<br>
 '''''aguerra_''''': hello everybody!!!<br>
 '''''CarlosRuiz''''': Hi Alejandro<br>
 '''''CarlosRuiz''''': nmicoud, testing IDEMPIERE-1707<br>
@@ Line 62: / Line 58: @@
 '''''JanThielemann''''': thank you as well<br>
 '''''CarlosRuiz''''': nmicoud, I refactored some things on MCountry<br>
 '''''CarlosRuiz''''': local tests passed - can you please test it too?<br>
 '''''nmicoud''''': ok, will do this<br>
 '''''JanThielemann''''': jira ping pong :)<br>
 '''''CarlosRuiz''''': JanThielemann, I asked displaylogic because I was testing with the tab "POS Payment" and it works fine<br>
@@ Line 111: / Line 97: @@
 '''''CarlosRuiz''''': dirty trick<br>
 '''''JanThielemann''''': yep works<br>
 '''''JanThielemann''''': you can close the ticket if you want<br>
 '''''JanThielemann''''': i am satisfied with this solution<br>
 '''''CarlosRuiz''''': maybe an annotation on DisplayLogic for tab mentioning that context variables must be fields to be evaluated would be worthy<br>
 '''''CarlosRuiz''''': so, the ticket can be a documentation improvement <br>
 '''''nmicoud''''': @CarlosRuiz : hi, i've tested your patch for https://idempiere.atlassian.net/browse/IDEMPIERE-1707 and it seems ok. at least i was not able to reproduce the issue. i will patch the production instance with it<br>
 '''''CarlosRuiz''''': thanks nmicoud <br>