IDempiere/FullMeeting20120208

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