CarlosRuiz: full meeting

2012-09-05T18:56:54Z

full meeting

New page

⇐
[[IDempiere|Table of Contents]] |
[[IDempiere/Full Meeting Minutes|Full Meeting Minutes]] |
Full Meeting 2012-09-05


'''''CarlosRuiz''''': Good morning 
'''''nmicoud''''': Bonjour 
'''''CarlosRuiz''''': Nicolas, a question about IDEMPIERE-332 
'''''nmicoud''''': i'm listening 
'''''CarlosRuiz''''': what is the advantage of making the AD_Org_ID column configurable 
'''''CarlosRuiz''''': not criticizing - just trying to understand 
'''''CarlosRuiz''''': is about AD_OrgTrx_ID ? 
'''''nmicoud''''': i duplicate the behaviour of date column 
'''''nmicoud''''': in 99%, it will be AD_Org_ID ; but if someone wants to use a CustomOrg_ID column, then he could 
'''''nmicoud''''': to be honest, i've done it mindlessly 
'''''a42niem''''': hi 
'''''CarlosRuiz''''': hi Dirk 
'''''CarlosRuiz''''': well - there are several documents in iDempiere that have AD_OrgTrx_ID 
'''''CarlosRuiz''''': I'm thinking if is a good thing 
'''''nmicoud''''': maybe we could initialize the column with AD_Org_ID ? 
'''''CarlosRuiz''''': it complicates a little the configuration - but sounds like it could be useful with such column 
'''''nmicoud''''': fine 
'''''a42niem''''': hi Carlos, did you see the comment from Daniel in 246 about migration scripts appearing "too late" 
'''''CIA-78''''': iDempiere: elainetan * f73cb5decd06 r7607 / (5 files in 5 dirs): IDEMPIERE-373 Implement User Locking - fix the default date password change and use translatable message 
'''''CIA-78''''': iDempiere: hengsin * 233e5663f97c r7608 / (11 files in 9 dirs): Merge with 626f88fda0dd1ee86a114a49a4fea4f04f90a09e 
'''''CIA-78''''': iDempiere: globalqss * 4b7f802886a7 r7609 /migration/360lts-release/ (2 files in 2 dirs): IDEMPIERE-373 Implement User Locking / minor fix on migration script 
'''''a42niem''''': hi Nicolas 
'''''CarlosRuiz''''': yes - that's why we implemented the register_migration_script 
'''''CarlosRuiz''''': it has become difficult to keep track of the migration scripts applied 
'''''CarlosRuiz''''': so, the idea is that you can know now checking AD_MigrationScript table 
'''''nmicoud''''': hi Dirk 
'''''a42niem''''': yeah, we discussed about such kind of solution a while back i think 
'''''CarlosRuiz''''': yep 
'''''CarlosRuiz''''': it becomes too difficult also trying to manage 10 concurrent developers - as at this stage of the project 
'''''CarlosRuiz''''': so, reservation of migration script helps to avoid developers renaming and keeping sync with numbering 
'''''hahmed''''': Hello everyone 
'''''nmicoud''''': Hi 
'''''CarlosRuiz''''': Hello hahmed 
'''''hahmed''''': great improvements lately!! Still trying to keep up with the updates in Jira after being away for a few weeks 
'''''hahmed''''': anyone working on http://jira.idempiere.com/browse/IDEMPIERE-379 
'''''hahmed''''': If not I would like to work on it 
'''''CarlosRuiz''''': let me check ... 
'''''buildmaster''''': Project iDempiere build #347: SUCCESS in 21 min: http://jenkins.idempiere.com/job/iDempiere/347/ 
'''''buildmaster''''': * globalqss: IDEMPIERE-373 Implement User Locking / minor fix on migration script 
'''''buildmaster''''': * hengsin: Merge with 626f88fda0dd1ee86a114a49a4fea4f04f90a09e 
'''''buildmaster''''': * elainetan: IDEMPIERE-373 Implement User Locking - fix the default date password change and use translatable message 
'''''CarlosRuiz''''': hahmed 
'''''hahmed''''': Yes Carlos 
'''''CarlosRuiz''''': Deepak is working on it - but he just told me he's stagnated on that one - and it will be great if you can move it ahead 
'''''hahmed''''': Ok great, if he can share his work I will try to take that forward 
'''''hahmed''''': Also I am not sure if it was covered during past meetings I missed, but I can't log in to demo.idempiere.com anymore using standard built-in accounts (GardenAdmin SuperUser etc) 
'''''hahmed''''': gives me password error 
'''''CarlosRuiz''''': he can upload a patch for what he has done - but please feel free to start it again if you find it easier 
'''''CarlosRuiz''''': also I think he has some design notes that he'll be adding to comments 
'''''CarlosRuiz''''': ah yes - that's covered in past meetings and forums :-) 
'''''a42niem''''': i recently had an interesting experience when importing a bank statement 
'''''CarlosRuiz''''': hahmed - users are now 
'''''a42niem''''': it seemed not to be there until i discovered that the date was in the year 0012 and not in 2012 
'''''CarlosRuiz''''': superuser @ idempiere.com (with the spaces) -> pass System 
'''''CarlosRuiz''''': system @ idempiere.com / System 
'''''CarlosRuiz''''': admin @ gardenworld.com / GardenAdmin 
'''''CarlosRuiz''''': user @ gardenworld.com / GardenUser 
'''''hahmed''''': CarlosRuiz: thanks I checked the thread 
'''''a42niem''''': i had the idea to validate the dates in import against the calendar. WDYT? 
'''''CarlosRuiz''''': that's driven by a sysconfig key - so is easy for some tester to change it again and we'll be back to the username approach 
'''''hahmed''''': I have an opinion regarding http://jira.idempiere.com/browse/IDEMPIERE-375 
'''''hahmed''''': I don't think its required/suitable for iDempiere 
'''''CarlosRuiz''''': why? 
'''''hahmed''''': Every user in iDempiere is a known user (Customer, Employee, Vendor) 
'''''hengsin''''': it is useful for a hosting environment 
'''''nmicoud''''': I already faced it Dirk ; it could be useful to check if date is in the calendar if we find a C_DocType_ID column ; WDYT ? 
'''''hahmed''''': unlike hotmail or others where the users are not known 
'''''hahmed''''': and in iDempiere having reset my password by using questions just adds additional security risk (I might not know the password but have better chance to guess the answer) 
'''''CarlosRuiz''''': Dirk - sounds like a good idea 
'''''CarlosRuiz''''': hahmed - yes, that's intended for multi-tenant environments, and just must work if the email is used as login - and the idea is to send the password to registered email 
'''''hahmed''''': And I have not seen "forgot my password" feature for any private application (private email servers like exchange, zimbra; nor any ERP systems or private CRM systems) 
'''''CarlosRuiz''''': just checked netsuite -> they have forgot my password 
'''''CarlosRuiz''''': salesforce too 
'''''CarlosRuiz''''': I think is common on hosted envs 
'''''hahmed''''': both available to unknown members 
'''''CarlosRuiz''''': nmicoud, we checked the org approach for IDEMPIERE-332 with Heng Sin - and we like it 
'''''nmicoud''''': :) 
'''''CarlosRuiz''''': sounds useful when you have lots of organizations - i.e. points of sales 
'''''CarlosRuiz''''': now - the suggestion on your last comment seems like must be implemented 
'''''nmicoud''''': avoid hardcoding sequence ? 
'''''CarlosRuiz''''': not sure how is implemented now - you said hardcoded - but it sounds useful to add the @OrgValue@ as you advised 
'''''nmicoud''''': The sequence is hardcoded : somethig like OrgValue_Year/Month 
'''''nmicoud''''': Maybe adding a field which could store sequence; ie @OrgValue@_@Year@/@Month@-@DocumentNo@ 
'''''CarlosRuiz''''': I think prefix do that 
'''''nmicoud''''': yes, but this prefix needs to be check in order to avoid duplicate documentNo 
'''''nmicoud''''': that's why i hardcoded it ; did not know how to check sequence from a 'prefix' field (we should also use a suffix field) 
'''''CarlosRuiz''''': I don't understand 
'''''CarlosRuiz''''': this prefix @OrgValue@_@Year@/@Month@-@DocumentNo@ - cannot throw duplicates 
'''''CarlosRuiz''''': or am I understanding wrong? 
'''''nmicoud''''': Yes, but if (as a user) i change this prefix to @Year@/@Month@-@DocumentNo@ ; there will be a problem when org B will create a document with the same number as Org A did previously 
'''''CarlosRuiz''''': ah yes - but that would be wrong configuration - I would not worry too much about that - as is just one time config, and the document won't be saved anyways 
'''''nmicoud''''': I agree, but that could be a risk ; anyway, this can be handle through access role 
'''''CarlosRuiz''''': yep - users must not play with sequences or doctypes - I had a bad experience with that 
'''''CarlosRuiz''''': a user changed the docbasetype of invoice to be credit memo - and the invoices started to subtract balance :-D 
'''''nmicoud''''': that's funny ;) 
'''''nmicoud''''': but not for everyone 
'''''a42niem''''': sorry, was away. thanks for the feedback 
'''''nmicoud''''': So, if we use current prefix field, there is no modification to do ? 
'''''CarlosRuiz''''': don't know if you added the code to manage @OrgValue@ 
'''''nmicoud''''': i think i did it ( but not checked) 
'''''CarlosRuiz''''': ah good - so if it's done we would not need additional things 
'''''nmicoud''''': did you manage to fix the error that appears on postgresql ? 
'''''CarlosRuiz''''': no - I was making some performance tests was to avoid the db functions at all 
'''''CarlosRuiz''''': and results were fine - is the same to use just java code than calling the db function 
'''''nmicoud''''': that would be easier to have a single way! 
'''''CarlosRuiz''''': I'll try to check again performance with a bigger test case - like importing 10.000 products - and if the results are ok - I think we can deprecate the DB functions and just leave the java code on MSequence 
'''''nmicoud''''': i agree 
'''''CarlosRuiz''''': less duplicated code to maintain 
'''''nmicoud''''': and easier to test : everything will be in a single class (and not on a class and 2 functions) 
'''''CarlosRuiz''''': hmmm - at least the document part - the table ID is useful for migrations 
'''''nmicoud''''': what are you talking about ? what is table ID ? 
'''''CarlosRuiz''''': I mean the nextIDFunc 
'''''CarlosRuiz''''': all your development is about document sequences 
'''''CarlosRuiz''''': and we're thinking to drop that from db and just leave the java part 
'''''CarlosRuiz''''': but on nextID and nextIDFunc we control also the table ID sequences - and that's useful for migrations and other stuff 
'''''nmicoud''''': that could be done in java ? (like i guess it is done for postgre) ? 
'''''CarlosRuiz''''': it's fine - we can preserve that part - is not related to prefixes, neither year/org sequences 
'''''nmicoud''''': goo 
'''''nmicoud''''': d 
'''''CarlosRuiz''''': guys thanks a lot for attending - I'm going out for 1h

IDempiere/FullMeeting20120905 - Revision history

CarlosRuiz: full meeting