IDempiere/FullMeeting20120905

⇐ Table of Contents | 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