CarlosRuiz: full meeting

2012-02-08T23:06:36Z

full meeting

New page

⇐
[[IDempiere|Table of Contents]] |
[[IDempiere/Full Meeting Minutes|Full Meeting Minutes]] |
Full Meeting 2012-02-08


'''''CarlosRuiz''''': Morning 
'''''mzuniga_ergio''''': Good morning Carlos 
'''''Martin____''''': Morning Carlos 
'''''nicolas_''''': Hello everyone 
'''''a42niem''''': wow, exactamente: (14:00:00) CarlosRuiz 
'''''a42niem''''': hi Carlos :) 
'''''CarlosRuiz''''': atomic clock :-) 
'''''mzuniga_ergio''''': :-) 
'''''CarlosRuiz''''': as usual - no agenda, just open meeting to chat about technical/functional things 
'''''tbayen''''': Hi and good morning. 
'''''CarlosRuiz''''': I would like to ask for votes on your preferred bug or feature request to be reviewed/solved 
'''''CarlosRuiz''''': from this list 
'''''CarlosRuiz''''': http://jira.idempiere.com/secure/IssueNavigator.jspa?reset=true&jqlQuery=project+%3D+IDEMPIERE+AND+status+%3D+Open+ORDER+BY+priority+DESC%2C+key+DESC 
'''''CarlosRuiz''''': do you know that in JIRA you can vote for tickets? 
'''''tbayen''''': I want to do a small workshop at the weekend. Are the database seed problems solved so that I can install it from base? 
'''''suman_''''': Hi, This is Suman from Walkingtree 
'''''CarlosRuiz''''': I applied scripts until ..... checking .... 
'''''tbayen''''': (a clean install without a before running 361) 
'''''CarlosRuiz''''': Hi suman_ 
'''''CarlosRuiz''''': tbayen, I added a file named 
'''''suman_''''': Aplologies for being late 
'''''CarlosRuiz''''': org.adempiere.server-feature/data/seed/LAST_SCRIPT_APPLIED_ON_THIS_SEED 
'''''CarlosRuiz''''': suman_, you know the rules! 
'''''CarlosRuiz''''': :-D no rules :-) 
'''''CarlosRuiz''''': tbayen, the last migration script applied on the actual seed on the repository is 809_IDEMPIERE23.sql 
'''''CarlosRuiz''''': so, if you install it from there, is recommended you apply 810 to 815 
'''''suman_''''': :) 
'''''tbayen''''': CarlosRuiz, I will try it with your documentation in your wiki and complain if everything is not perfect. :-) Thanks! 
'''''CarlosRuiz''''': suman_, did you receive my answer on http://red1.org/adempiere/viewtopic.php?f=28&t=1507 
'''''hengsin''''': thomas, note that there might be a problem with the buckminster import on window machine. 
'''''a42niem''''': recently i had the problem to identify for a certain database which of the scripts had not been applied already to it 
'''''tbayen''''': No windows here. Baeh! 
'''''tbayen''''': hengsin, No windows here. Baeh! 
'''''CarlosRuiz''''': yes Dirk, if you don't follow the order and verify each one - it ca become a nightmare to realize which one is applied 
'''''tbayen''''': How about a table of applied scripts? :-) 
'''''a42niem''''': there is table ad_migrationscript which will be uopdated if you apply the migrationscript from within adempiere 
'''''CarlosRuiz''''': it is there - just that we are not using it :-) 
'''''a42niem''''': right 
'''''tbayen''''': Thanks CarlosRuiz, I could not believe such a thing is not there - I learned in ADempiere there is a table for everything. 
'''''a42niem''''': therefor it would be interesting to change the script to automatically put an entry into this table 
'''''a42niem''''': and compare if there is already an entry by that name and skip it then 
'''''tbayen''''': Perhaps there should be a standard convention to create an entry in this table inside the script?!? 
'''''a42niem''''': script refers to migrate_oracle.sh in my case 
'''''CarlosRuiz''''': was wondering 
'''''CarlosRuiz''''': this is the window that was contributed by Adaxa http://www.adempiere.com/AD_Migration 
'''''CarlosRuiz''''': and this is a similar/different proposal from Fernando Lucktemberg http://www.adempiere.com/Migration_Script_Manager 
'''''a42niem''''': any insights and/or preferences? 
'''''CarlosRuiz''''': I think long term goal is to get rid off migration scripts in favor of 3pack 
'''''CarlosRuiz''''': but with what we have actually I would prefer a java process that automate the thing 
'''''CarlosRuiz''''': it can be something like: 
'''''CarlosRuiz''''': - download migration scripts from a predefined URL 
'''''tbayen''''': Yes - many of the things in the database should be packed into modules. 
'''''CarlosRuiz''''': - check in AD_Migration table if it was already applied 
'''''CarlosRuiz''''': - apply in order 
'''''CarlosRuiz''''': - stop on any failure for user to review 
'''''CarlosRuiz''''': something like that, but I can foresee problems with that approach - as a partially migrated database can stop the client from starting 
'''''a42niem''''': maybe first present a list of found scripts and ask user which ones to apply 
'''''a42niem''''': like with mass delete 
'''''hengsin''''': carlos, that's not practical if it is not highly reliable. 
'''''CarlosRuiz''''': yes, you can end with a half migrated db that cannot run server neither client 
'''''tbayen''''': Some days ago we discussed that there is no clean way to enter data without going through the persistence layer. I accepted this as a rule. Why not accept a similar rule for migration scripts and do some Java around it with checks and bookkeeping. 
'''''nicolas_''''': personnaly, i apply migration scripts manually ; i find it more reliable ; why not adding an update statement at the end of each scripts ? update AD_System set LastMigrationScript = '888'; ? 
'''''CarlosRuiz''''': sounds good suggestion as an initial relief - or insert into ad_migration '888' 
'''''red1''''': ok.. i am showing this chatroom to the audience in Sao Paulo here… 
'''''nicolas_''''': i would prefer only one field to store the last migration applied ; is there an interest to keep all of them ? 
'''''a42niem''''': makes sense. you just have to remember to do it and synchronize it to the title 
'''''tbayen''''': Thats what I meant in the first place with "a standard convention". 
'''''CarlosRuiz''''': :-) Bem-vindo comunidade brasileira 
'''''CarlosRuiz''''': sure - is simpler 
'''''CarlosRuiz''''': the insert will be more complicated and prone to problems 
'''''red1''''': now talking about hengsin 
'''''red1''''': :D 
'''''red1''''': his contributions… to the crowd here in Brazil… about 35 has come here from all over Brazil 
'''''red1''''': so please wave to them , hengsin ":D 
'''''red1''''': :D 
'''''hengsin''''': hi 
'''''red1''''': ok they are saying OLA!!! back :D 
'''''red1''''': talking about the iDEmpiere = oSGi project 
'''''red1''''': and the UUID component 
'''''CarlosRuiz''''': all - do we have agreement to add AD_System.LastMigrationScriptApplied column? and define it as a standard to finish migration scripts with UPDATE AD_System SET LastMigrationScriptApplied='888'; 
'''''CarlosRuiz''''': from my side I would say yes - very simple and we can do it immediately 
'''''nicolas_''''': Yep ! 
'''''nicolas_''''': +1 
'''''tbayen''''': +1 
'''''CarlosRuiz''''': :-) nicolas_ as it was your idea - would you mind opening the corresponding JIRA ticket and I'll create the corresponding migration script 
'''''red1''''': now talking about CHE Carlos Ruiz :D 
'''''nicolas_''''': I'm working on windows (sorry :-)) and have created a batch file that add this kind of statement 
'''''CarlosRuiz''''': Obrigado 
'''''nicolas_''''': ok carlos, i will do this 
'''''red1''''': ah .. they tell me you say thanks1 ;D 
'''''CarlosRuiz''''': nicolas_, did instructions for bitbucket and eclipse worked on your windows? 
'''''nicolas_''''': yes, i could download sources from bitbucket 
'''''nicolas_''''': but don't try to launch it yet from eclipse 
'''''CarlosRuiz''''': wondering if the LastMigrationScriptApplied must be a number 
'''''CarlosRuiz''''': and the update must be rephrased to 
'''''nicolas_''''': no it could the the filename 
'''''CarlosRuiz''''': UPDATE AD_System SET LastMigrationScriptApplied=888 WHERE LastMigrationScriptApplied<888; 
'''''nicolas_''''': 2 information : the number and the purpose of the script ! 
'''''CarlosRuiz''''': just concerned that if you reapply a previous migration script it will overwrite your "last" information 
'''''nicolas_''''': 2 fields then ? lastApplied, MaxApplied ? 
'''''tbayen''''': If we really think this to the end we have a table of all applied scripts and an insert. We have to choose the trade-off between simplicity and more information. I have not enough experience in this area and would Carlos decide where the best tradeoff point lies. 
'''''CarlosRuiz''''': :-) my concern about that is to make the contribution process harder (it is already hard) 
'''''tbayen''''': a PMM (Perfect Migration Manager) may be a project of its own. I would not begin this now but while thinking about modularizing functionality. For now it seems enough to have one standard UPDATE line in the scripts. 
'''''CarlosRuiz''''': I think better we create an "applier" 
'''''CarlosRuiz''''': be java or script 
'''''CarlosRuiz''''': the problem with script is that I think is easy in linux - but not in windows 
'''''CarlosRuiz''''': and a java program can work on both 
'''''CarlosRuiz''''': the "applier" read a file - apply it - create a record on AD_Migration and even it could attach the output 
'''''CarlosRuiz''''': and mark it as "Completed" / "Error" depending on the output 
'''''nicolas_''''': i think the most reliable is to see the content of the script while applying it ; not sure that using an 'applier' is a good thing; i prefer apply them using sql Developer 
'''''nicolas_''''': and only store the last (or the max) applied ; if there is an error, i can handle it immediatly 
'''''hengsin''''': carlos, I'm testing eclipse indigo and it seems there are errors with the mercurial plugin. what's the version you use there ? any issues ? 
'''''CarlosRuiz''''': within eclipse I'm not having problems 
'''''CarlosRuiz''''': but with buckminster headless it show mercurial errors 
'''''CarlosRuiz''''': Indigo Service Release 1 
'''''hengsin''''': i'm also using indigo sr1 and there are errors in the error log although it seems to work 
'''''nicolas_''''': at the beginning of this session, Carlos asked for a vote to choose next jira tickets to be resolved. I would say 'IDEMPIERE-102 - Add FirstName and LastName on BPartner/User ' ; which seems quite simple and very useful 
'''''CarlosRuiz''''': yes Nicolas - my point is that you can navigate to that ticket 
'''''CarlosRuiz''''': and push a little Vote button there 
'''''CarlosRuiz''''': you can vote on tickets from others, not yours 
'''''nicolas_''''': done ! 
'''''CarlosRuiz''''': excellent 
'''''nicolas_''''': if there are no other subject, would like to talk about toolbar restrictions ? 
'''''CarlosRuiz''''': sure 
'''''nicolas_''''': ok ; http://jira.idempiere.com/browse/IDEMPIERE-129 
'''''nicolas_''''': this development allow to hide buttons from toolbar and menu. You only specify restrictions (for a role and/or a window) 
'''''nicolas_''''': it has been implemanted in swing and seems to work properly since one week 
'''''nicolas_''''': you say that you have enhacement in mind 
'''''nicolas_''''': and they may be implemanted by extending it 
'''''CarlosRuiz''''': so, as I see we have two toolbars? one for common windows and other for report viewers 
'''''nicolas_''''': yes 
'''''nicolas_''''': tollbar for window = New, Save, Find, ... 
'''''nicolas_''''': toolbar for viewer : Print, Summary, Customize Report, ... 
'''''CarlosRuiz''''': I like your idea of hiding/showing per role 
'''''CarlosRuiz''''': but don't like the "hardcoded" part 
'''''CarlosRuiz''''': so - I'm thinking if we can make it official - to have a formal definition of the toolbars - and their buttons 
'''''CarlosRuiz''''': and with that in mind - then you can think on extending the toolbar via dictionary 
'''''nicolas_''''': Sounds cool ; so the toolbarS would be defined in a new table ? (per role ?) 
'''''tbayen''''': I would like to have more buttons not less... CarlosRuiz pointed me to http://www.adempiere.com/ADempiere_Multiple_Record_Action_Field Perhaps we should join efforts to "customize" the toolbars. 
'''''nicolas_''''': Just a precision ; some users don't need too much buttons ; that frighten them ; 
'''''nicolas_''''': we could have more buttons but not show all of them 
'''''CarlosRuiz''''': I have had lot of histories with toolbar - one user deleted "accidentally" 52 orders - and the manager of the company paid us to drop the "delete multiple records" from the toolbar 
'''''CarlosRuiz''''': that's called here "selling the couch" 
'''''tbayen''''': Yes - waht I wanted to say: I want customized buttons with the ability to start some user defined process. 
'''''nicolas_''''': Would be a great enhancement also ! 
'''''hengsin''''': the "delete selected" hack is pretty confusing, that justify to have another ticket for it. 
'''''nicolas_''''': Cleaner that adding button in a window 
'''''hengsin''''': there are actually two type of customization here - 1) adding button 2) provide additional options for a button 
'''''CarlosRuiz''''': 3) allow hiding buttons per role 
'''''hengsin''''': 3) is more appropriate to be classify as a security feature 
'''''CarlosRuiz''''': yes - and that's IDEMPIERE-129 about 
'''''nicolas_''''': So we can store all buttons in a table ; they can be of 2 kind : 1 - hardcoced (New, Save, ...) 2 - customizable ones (start processes, launch reports, ...) 
'''''nicolas_''''': and build toolbarS using this table ? 
'''''hengsin''''': we have to be careful here - 1) must be minimize to avoid bloat UI, very confusing. 
'''''hengsin''''': 2) is what we have to try to maximize. 
'''''tbayen''''': I would like to have the possibility of buttons with pull down menus. So I can have "report" button and choose one of some jasper templates via a menu. 
'''''a42niem''''': i just had shown "order positions" as included tab to a customer 
'''''hengsin''''': thomas, yes, that's #2 an example fo #2 above. 
'''''a42niem''''': and they want some of the buttons removed 
'''''hengsin''''': I don't like the current included tab model, would prefer that to be as a separate pane from the header ( split pane ) 
'''''CarlosRuiz''''': I don't like that it allows just 1 included tab - it could be done differently to allow multiple 
'''''a42niem''''': sounds interesting - how easy would that be done? 
'''''hengsin''''': yeah but 1 included tab is very simple to resolve 
'''''CarlosRuiz''''': agree that a split pane is visibly better - the actual embedded is confusing 
'''''CarlosRuiz''''': visually better 
'''''hengsin''''': a42niem, quite a lot of work unfortunately. 
'''''a42niem''''': ok 
'''''hengsin''''': carlos, yes, bad presentation, that's why I oppose it from day one. 
'''''nicolas_''''': not agree ; included tab are very useful ; for instane, you can see in a single view header and lines 
'''''a42niem''''': but currently it seems the easiest solution to provide a fast input without creating a special form 
'''''CarlosRuiz''''': hengsin - the actual approach is to define the detail tab on the ID of the parent - I suggested initially something different to define the parent tab on each tab - so you can have multiple 
'''''CarlosRuiz''''': nicolas_, we're not saying that included tab is not useful - just looking for improvements on the approach - it was somewhat poor and buggy 
'''''hengsin''''': ah, my initial alternative proposal is still there - http://www.adempiere.com/Tab_Group 
'''''nicolas_''''': ok, 
'''''nicolas_''''': Tab groups seems quite good also ! and co-exists with included tabs 
'''''a42niem''''': that looks interesting. is it true that it has only one row of icons on top? 
'''''tbayen''''': I like the Tab_Group look. But someone has to decide which toolbar buttons you need for this second Tab_Group. (It's the same with included Tabs.) 
'''''tbayen''''': a42niem, I understand this just as a proof of concept, or what says hengsin ? 
'''''a42niem''''': enabling and disabling depending on which tab you selected might be sufficient 
'''''a42niem''''': thats why i am asking 
'''''tbayen''''': Hmmm... We could try that but it might be very un-intuitive and confusing. 
'''''CarlosRuiz''''': rereading the whole thread - Heng Sin also proposed http://www.adempiere.com/index.php/Multi_Page_Tab 
'''''nicolas_''''': those multi page tab are similar to 'Field group tab' ? 
'''''tbayen''''': What is the difference to field groups? 
'''''CarlosRuiz''''': hengsin, I think your approach of Tab Group deserves to be implemented - I for sure will prefer that over the actual master/detail approach 
'''''CarlosRuiz''''': a way to configure and save the preferred columns size and orders in grid mode is very useful too 
'''''CarlosRuiz''''': back to nicolas_ IDEMPIERE-129 
'''''CarlosRuiz''''': I would like to have a table where we can have "visual components" to and allow restrictions per role on a detailed basis for each component 
'''''nicolas_''''': i don't understand what you mean 
'''''nicolas_''''': i don't understand what you mean 
'''''CarlosRuiz''''': with that we can drop the 11 "Allow Info" fields on this window http://www.adempiere.com/ManPageW_Role#Tab:_Role 
'''''nicolas_''''': oops 
'''''nicolas_''''': ok 
'''''nicolas_''''': One table to define all access to toolbar and menu (New, Save, Info, ...) 
'''''CarlosRuiz''''': I mean - in your document you propose a list for "Restriction" 
'''''hengsin''''': "a way to configure and save the preferred columns size and orders in grid mode is very useful too" - we have implemented ad_tab_customization to allow user doing that 
'''''CarlosRuiz''''': I propose to make it in dictionary - something like AD_VisualComponent 
'''''nicolas_''''': And this table is used for building toolbar (in createMenu method) ? 
'''''CarlosRuiz''''': in AD_VisualComponent you could define many things - dashboard panels - info window links - toolbar buttons - and then configure permissions per role 
'''''CarlosRuiz''''': in a table AD_VisualComponentAccess 
'''''nicolas_''''': it would be a better approah to only add what is needed (and not remove what is restricted) 
'''''hengsin''''': thomas, that's not field group but break a form into multiple page. I think we do have horizontal tab for field group in swing 
'''''CarlosRuiz''''': ok - then AD_VisualComponentRestrict can be better 
'''''CarlosRuiz''''': by default you're allowed - and if defined in such table is hidden 
'''''hengsin''''': carlos, for info, isn't it more natural to just do ad_infowindow and ad_infowindow_access ? 
'''''nicolas_''''': Yes,otherwise, you have to add every entries for every roles 
'''''CarlosRuiz''''': at this moment the 11 info windows seems to be hardcoded 
'''''CarlosRuiz''''': 13 info windows actually 
'''''nicolas_''''': but how could you achieve without 'hard coding' ? 
'''''CarlosRuiz''''': hengsin, do you think AD_VisualComponent idea is good? 
'''''hengsin''''': I think is good but I don't agree that we should use it for info. we really must complete the ad_infowindow stuff, that's one major pain with adempiere 
'''''CarlosRuiz''''': we can have a defined list of VisualGroup for "Toolbar Window" - "Toolbar Report Viewer" - "Toolbar Jasper Viewer" - "About window" - "Other window components" (like the record info button) 
'''''CarlosRuiz''''': a Seqno, Name and ComponentType - and a java class to implement some sort of configurable interface in future 
'''''CarlosRuiz''''': and then with such table we can implement AD_VisualComponentRestrict and solve IDEMPIERE-129 very naturally 
'''''CarlosRuiz''''': agree with you that Info Windows deserves a different approach 
'''''CarlosRuiz''''': what do you think nicolas_ ?? is that feasible to solve IDEMPIERE-129 ? 
'''''nicolas_''''': yes, my purpose was to be capable of limiting (and control) items of toolbar ; with what you suggested, it should work 
'''''tbayen''''': I did something similar. You should create a well-thought interface for the buttons. So you can implement a search button that has access to the actual data in the tab. 
'''''CarlosRuiz''''': tbayen, easy if you pass AD_Table_ID and Record_ID as parameters to the interface 
'''''CarlosRuiz''''': ok - let's try that approach if you want 
'''''tbayen''''': Yes 
'''''CarlosRuiz''''': nicolas_, do you want to work on that? I can help you creating the tables with official IDs 
'''''CarlosRuiz''''': or I can set up your credentials for that if you prefer 
'''''nicolas_''''': yes, i can try 
'''''nicolas_''''': Let's make it simple, you can create tables 
'''''CarlosRuiz''''': ok - preparing first version - I'll upload the migration scripts to the jira ticket 
'''''nicolas_''''': i'll recover migration script 
'''''nicolas_''''': and it will update the LastMIgrationScriptApplied ;-) 
'''''nicolas_''''': ok 
'''''CarlosRuiz''''': guys 
'''''CarlosRuiz''''': we're approaching to 1000 in migration scripts 
'''''CarlosRuiz''''': is it ok if we start prefixing then with a 0 ?? 
'''''CarlosRuiz''''': 0816_AAAA 
'''''CarlosRuiz''''': 0816_AAAA.sql 
'''''nicolas_''''': yes we can ! 
'''''CarlosRuiz''''': ok guys - if there are not something else we can declare this meeting ended - right? 
'''''tbayen''''': ok - thanks! 
'''''CarlosRuiz''''': I'll upload the chat on the usual site - and update the jira ticket to note what we reviewed here 
'''''nicolas_''''': ok thanks carlos 
'''''CarlosRuiz''''': did you create the ticket for LastMigrationScriptApplied new field? 
'''''nicolas_''''': not yet , i'm doing it now 
'''''CarlosRuiz''''': ok 
'''''CarlosRuiz''''': thanks 
'''''CarlosRuiz''''': c u later guys 
'''''CarlosRuiz''''': if red1 is still connected - then -> cumprimentos a o Brasil

IDempiere/FullMeeting20120208 - Revision history

CarlosRuiz: full meeting