Difference between revisions of "IDempiere/FullMeeting20140312"

From WikiQSS
(full meeting)
 
(drop JIRA notifications from log)
 
Line 30: Line 30:
 
'''''red1''''': and also global babes<br>
 
'''''red1''''': and also global babes<br>
 
'''''aguerra_''''': hello everybody!!!<br>
 
'''''aguerra_''''': hello everybody!!!<br>
'''''Not-005''''': [iDempiere] CarlosRuiz_globalqss pushed 1 commit to release-2.0 [+0/-0/±1] https://bitbucket.org/idempiere/idempiere/commits/<br>
 
'''''Not-005''''': [iDempiere] jarboleda 7d46b76 - IDEMPIERE-1775 PackOut process is not exporting UUIDs references for fields M_Locator_ID and C_Location_ID<br>
 
'''''Not-005''''': [IDEMPIERE] carlosruiz_globalqss updated IDEMPIERE-1775 status set to "Resolved" -resolution set to "Fixed"<br>
 
'''''Not-005''''': [IDEMPIERE] http://idempiere.atlassian.net/browse/IDEMPIERE-1775<br>
 
 
'''''CarlosRuiz''''': Hi Alejandro<br>
 
'''''CarlosRuiz''''': Hi Alejandro<br>
 
'''''CarlosRuiz''''': nmicoud, testing IDEMPIERE-1707<br>
 
'''''CarlosRuiz''''': nmicoud, testing IDEMPIERE-1707<br>
Line 62: Line 58:
 
'''''JanThielemann''''': thank you as well<br>
 
'''''JanThielemann''''': thank you as well<br>
 
'''''CarlosRuiz''''': nmicoud, I refactored some things on MCountry<br>
 
'''''CarlosRuiz''''': nmicoud, I refactored some things on MCountry<br>
'''''Not-005''''': [iDempiere] CarlosRuiz_globalqss pushed 1 commit to release-2.0 [+0/-0/±1] https://bitbucket.org/idempiere/idempiere/commits/<br>
 
'''''Not-005''''': [iDempiere] globalqss 469f514 - Fix IDEMPIERE-1707 A single default country for all tenant<br>
 
 
'''''CarlosRuiz''''': local tests passed - can you please test it too?<br>
 
'''''CarlosRuiz''''': local tests passed - can you please test it too?<br>
 
'''''nmicoud''''': ok, will do this<br>
 
'''''nmicoud''''': ok, will do this<br>
'''''Not-005''''': [IDEMPIERE] carlosruiz_globalqss updated IDEMPIERE-1707 status set to "Resolved" -resolution set to "Fixed"<br>
 
'''''Not-005''''': [IDEMPIERE] http://idempiere.atlassian.net/browse/IDEMPIERE-1707<br>
 
'''''Not-005''''': [IDEMPIERE] carlosruiz_globalqss updated IDEMPIERE-1811<br>
 
'''''Not-005''''': [IDEMPIERE] [~jan.thielemann] how is your display logic?<br>
 
'''''Not-005''''': [IDEMPIERE] http://idempiere.atlassian.net/browse/IDEMPIERE-1811<br>
 
'''''Not-005''''': [IDEMPIERE] jan.thielemann updated IDEMPIERE-1811<br>
 
'''''Not-005''''': [IDEMPIERE] @OrderType@=VE and @OrderType@=RA<br>
 
'''''Not-005''''': [IDEMPIERE] http://idempiere.atlassian.net/browse/IDEMPIERE-1811<br>
 
 
'''''JanThielemann''''': jira ping pong :)<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>
 
'''''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>
 
'''''CarlosRuiz''''': dirty trick<br>
 
'''''JanThielemann''''': yep works<br>
 
'''''JanThielemann''''': yep works<br>
'''''Not-005''''': [IDEMPIERE] jan.thielemann updated IDEMPIERE-1811<br>
 
'''''Not-005''''': [IDEMPIERE] Workaround: @OrderType@=VE & @C_DocTypeTarget_ID@=@C_DocTypeTarget_ID@<br>
 
'''''Not-005''''': [IDEMPIERE] http://idempiere.atlassian.net/browse/IDEMPIERE-1811<br>
 
 
'''''JanThielemann''''': you can close the ticket if you want<br>
 
'''''JanThielemann''''': you can close the ticket if you want<br>
 
'''''JanThielemann''''': i am satisfied with this solution<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''''': 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>
 
'''''CarlosRuiz''''': so, the ticket can be a documentation improvement <br>
'''''Not-005''''': [IDEMPIERE] sjeffen updated IDEMPIERE-1806<br>
 
'''''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<br>
 
'''''Not-005''''': [IDEMPIERE] http://idempiere.atlassian.net/browse/IDEMPIERE-1806<br>
 
'''''Not-005''''': [IDEMPIERE] carlosruiz_globalqss updated IDEMPIERE-1806<br>
 
'''''Not-005''''': [IDEMPIERE] But if you make the field editable for normal users then the whole security measure is broken.<br>
 
'''''Not-005''''': [IDEMPIERE] http://idempiere.atlassian.net/browse/IDEMPIERE-1806<br>
 
'''''Not-005''''': [IDEMPIERE] sjeffen updated IDEMPIERE-1806<br>
 
'''''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!<br>
 
'''''Not-005''''': [IDEMPIERE] http://idempiere.atlassian.net/browse/IDEMPIERE-1806<br>
 
'''''Not-005''''': [IDEMPIERE] carlosruiz_globalqss updated IDEMPIERE-1806<br>
 
'''''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.<br>
 
'''''Not-005''''': [IDEMPIERE] http://idempiere.atlassian.net/browse/IDEMPIERE-1806<br>
 
'''''Not-005''''': [IDEMPIERE] sjeffen updated IDEMPIERE-1806<br>
 
'''''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<br>
 
'''''Not-005''''': [IDEMPIERE] http://idempiere.atlassian.net/browse/IDEMPIERE-1806<br>
 
'''''Not-005''''': [IDEMPIERE] carlosruiz_globalqss updated IDEMPIERE-1806<br>
 
'''''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<br>
 
'''''Not-005''''': [IDEMPIERE] http://idempiere.atlassian.net/browse/IDEMPIERE-1806<br>
 
'''''Not-005''''': [IDEMPIERE] carlosruiz_globalqss updated IDEMPIERE-1670 status set to "Resolved" -assignee set to "hieplq" -resolution set to "Fixed"<br>
 
'''''Not-005''''': [IDEMPIERE] http://idempiere.atlassian.net/browse/IDEMPIERE-1670<br>
 
'''''Not-005''''': [IDEMPIERE] hieplq updated IDEMPIERE-1674 labels set to "+Patch" -Attachment set to "IDEMPIERE-1674.patch"<br>
 
'''''Not-005''''': [IDEMPIERE] fix for 3 window: cost adjust, physical inventory, internal inventory<br>
 
'''''Not-005''''': [IDEMPIERE] http://idempiere.atlassian.net/browse/IDEMPIERE-1674<br>
 
'''''Not-005''''': [IDEMPIERE] hieplq updated IDEMPIERE-1674 status set to "Peer Review Queue"<br>
 
'''''Not-005''''': [IDEMPIERE] http://idempiere.atlassian.net/browse/IDEMPIERE-1674<br>
 
'''''Not-005''''': [IDEMPIERE] sjeffen updated IDEMPIERE-1806<br>
 
'''''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<br>
 
'''''Not-005''''': [IDEMPIERE] http://idempiere.atlassian.net/browse/IDEMPIERE-1806<br>
 
'''''Not-005''''': [IDEMPIERE] carlosruiz_globalqss updated IDEMPIERE-1806<br>
 
'''''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.<br>
 
'''''Not-005''''': [IDEMPIERE] http://idempiere.atlassian.net/browse/IDEMPIERE-1806<br>
 
'''''Not-005''''': [IDEMPIERE] hieplq updated IDEMPIERE-1806<br>
 
'''''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<br>
 
'''''Not-005''''': [IDEMPIERE] http://idempiere.atlassian.net/browse/IDEMPIERE-1806<br>
 
'''''Not-005''''': [IDEMPIERE] carlosruiz_globalqss updated IDEMPIERE-1806<br>
 
'''''Not-005''''': [IDEMPIERE] Hiep - do you mean http://wiki.idempiere.org/en/SQL_Process_(Form_ID-111) ?<br>
 
'''''Not-005''''': [IDEMPIERE] http://idempiere.atlassian.net/browse/IDEMPIERE-1806<br>
 
'''''Not-005''''': [IDEMPIERE] carlosruiz_globalqss updated IDEMPIERE-1806<br>
 
'''''Not-005''''': [IDEMPIERE] Hiep - do you mean [http://wiki.idempiere.org/en/SQL_Process_(Form_ID-111)] ?<br>
 
'''''Not-005''''': [IDEMPIERE] http://idempiere.atlassian.net/browse/IDEMPIERE-1806<br>
 
'''''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<br>
 
'''''Not-005''''': [IDEMPIERE] http://idempiere.atlassian.net/browse/IDEMPIERE-1808<br>
 
'''''Not-005''''': [IDEMPIERE] hieplq updated IDEMPIERE-1806<br>
 
'''''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.<br>
 
'''''Not-005''''': [IDEMPIERE] http://idempiere.atlassian.net/browse/IDEMPIERE-1806<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>
 
'''''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>
'''''Not-005''''': [IDEMPIERE] hieplq updated IDEMPIERE-1742 labels set to "+Patch" -Attachment set to "IDEMPIERE-1742.patch"<br>
 
'''''Not-005''''': [IDEMPIERE] http://idempiere.atlassian.net/browse/IDEMPIERE-1742<br>
 
'''''Not-005''''': [IDEMPIERE] hieplq updated IDEMPIERE-1742 status set to "Peer Review Queue"<br>
 
'''''Not-005''''': [IDEMPIERE] http://idempiere.atlassian.net/browse/IDEMPIERE-1742<br>
 
'''''Not-005''''': [iDempiere] CarlosRuiz_globalqss pushed 3 commits to release-2.0 [+0/-0/±4] https://bitbucket.org/idempiere/idempiere/commits/<br>
 
'''''Not-005''''': [iDempiere] hieplq cba8cc0 - IDEMPIERE-1670:log-in with ldap account fail<br>
 
'''''Not-005''''': [iDempiere] globalqss 26941a4 - IDEMPIERE-604 Fix implementation hiding SQL errors from user - all SQL errors are being shown as "timeout error"<br>
 
'''''Not-005''''': [iDempiere] globalqss 5f2b43f - IDEMPIERE-1536 Error running a report with SQL columns / thanks to Antonio Cañaveral for suggested patch<br>
 
'''''Not-005''''': [IDEMPIERE] carlosruiz_globalqss updated IDEMPIERE-1536 status set to "Resolved" -assignee set to "Carlos Antonio Ruiz Gomez" -resolution set to "Fixed"<br>
 
'''''Not-005''''': [IDEMPIERE] http://idempiere.atlassian.net/browse/IDEMPIERE-1536<br>
 
 
'''''CarlosRuiz''''': thanks nmicoud <br>
 
'''''CarlosRuiz''''': thanks nmicoud <br>

Latest revision as of 23:57, 12 March 2014

Table of Contents | 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!!!
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
CarlosRuiz: local tests passed - can you please test it too?
nmicoud: ok, will do this
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
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
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
CarlosRuiz: thanks nmicoud