IRC logs of #tryton for Friday, 2008-06-20

chat.freenode.net #tryton log beginning Fri Jun 20 00:00:01 CEST 2008
-!- irclog(n=irclog@tycho.b2ck.com) has joined #tryton01:25
-!- yangoon(n=mathiasb@p549F4B92.dip.t-dialin.net) has joined #tryton05:19
-!- gadaga(n=gael@sednaco19320-gw.clients.easynet.fr) has joined #tryton08:18
gadagahi08:18
udonogadaga: hi08:20
gadagaudono: hi08:20
-!- cedk(n=ced@gentoo/developer/cedk) has joined #tryton08:27
-!- Timitos(n=Timitos@88.217.184.172) has joined #tryton08:29
CIA-53tryton: htgoebel roundup * #143/add VAT number validation: [new] Validation of VAT ID is required for invicing to EU-countries without VAT. Validation for German ID-Holders is available at <http://evatr.b ...10:39
CIA-53tryton: htgoebel roundup * #107/Anmerkungen zu German Translations (Deutsche Übersetzungen): Hallo Franz, ein paar schnell heruntergeschriebene Dinge, die mir bei den Übersetzungen zu relations aufgefallen sind: Straße (bis) -> Straße ...10:41
-!- FWiesing(n=FWiesing@194.208.185.12) has joined #tryton11:24
FWiesinggood morning11:24
TimitosFWiesing: hi11:25
FWiesingTimitos: udono: do you read my e-mail from yesterday about linux-day?11:26
FWiesingwhat's your opinion?11:26
TimitosFWiesing: yes. i have to think about but sounds good11:26
udonoFWiesing: yes, I read it.11:26
FWiesingI got a call from a guy, which is interested - I will meet him in the afternoon11:27
udonoFWiesing: interested in what? LinuxDay? or tryton?11:28
FWiesing- he want to use the erp-system11:28
udonoFWiesing: ah, ok11:28
FWiesingin tryton - he didn't know the name!11:28
udonoabout Linuxday: This sounds interesting.11:30
FWiesingEnd of september it will be decided which presentations on the linux day are shown. It seems, that it is for commercial interested people - exactly our thing11:31
FWiesinglast year there was a presentation about document mangement (open source) - maybe this year agai11:31
FWiesingagain11:31
FWiesingso I think a presentation of erp/crm-systems would be a interest point on this day11:32
FWiesingbut I didn't know any details at the moment - end of september I can tell you more11:33
udonoFWiesing: its a small meeting, IMHO the right place for a first presentation...11:33
FWiesingIndeed - it's small - but last year there are 1.000 visitors11:34
FWiesinglast question - The link from my homepage is at the moment not public because I first want to hear your opinion - could I publish the text with information of the new erp-system?11:37
FWiesinghttp://www.roadrunnerserver.com/index.php?id=1911:38
TimitosFWiesing: ich sehe keinen grund, warum du das nicht online stellen könntest. leg einfach los.11:43
FWiesingok - it's just for your information.11:46
FWiesingafk11:46
FWiesingback11:56
-!- kultviech(n=kultviec@p5B0D1F14.dip0.t-ipconnect.de) has joined #tryton12:01
FWiesinghi kultviech12:02
-!- kultviech(n=kultviec@p5B0D1F14.dip0.t-ipconnect.de) has left #tryton12:15
FWiesingcu12:37
-!- FWiesing(n=FWiesing@194.208.185.12) has left #tryton12:37
Timitoscedk: hi14:03
cedkTimitos: hi14:04
Timitoscedk: lets talk about historical data, ok?14:05
cedkTimitos: ok, I have just a phone and I'm ready14:05
Timitoscedk: i will wait. don´t hurry.14:05
cedkTimitos: I'm back14:08
udonohi14:08
Timitoscedk: ok14:08
Timitoscedk: did you think about this topic since our meeting in the of april?14:09
cedka little14:09
cedkI have an idea about how to implement it14:09
Timitosi also made some thoughts. i think we should throw in what we have14:09
Timitosi also tried to find a solution how to implement it. but there are some issues open.14:10
Timitosso whats your idea?14:10
cedkI think modify the ORM to be able to create a history object that have the same DB columns than the original but whithout any constraint14:11
cedkthis object can be create on the fly with a attribute on the first object14:12
cedkso once we have it, each time the method write is call on the objec, it duplicate the record on the other table14:12
Timitosso we will have two tables for this object?14:13
cedkyes14:13
Timitosok14:13
cedkone real like now and one for the history14:13
Timitoswhy not trying to implement in the existing table?14:13
cedkafter that we modify the read function to accept a date argument14:13
cedkTimitos: I don't think that we can use easily the postgresql behavior that you send me previously14:14
Timitoscedk: i also think, that the behavior needs to be different.14:15
cedkit will be difficult to handle migration14:15
Timitoscedk: i think i throw in my thoughts now. i tried to find a solution for one table. then we can compare our ideas, ok?14:16
cedkok14:16
Timitosso, if you define an object with a historical table you need a field which puts all records together which belong to the same record (a little bit difficult to explain)14:18
Timitosso you have a record customer called "Heinz" an every time you change a field of the record heinz, a new record will made.14:19
cedkit must be the id as we use it as external key14:19
Timitosthis is similar to what you want to do with the second table14:19
Timitosbut the id is for all records belonging to "Heinz" the same, right?14:20
Timitosso now, if you open the record in a view always the record with the newest creation date will be shown14:22
udono... cedk: you can do that with ORDER BY date asc LIMIT 1 ...14:23
Timitosyes.14:23
Timitosnow you use this table in a relation14:23
Timitosif you choose a record you must use the "id" which is for all records which belong together the same.14:24
Timitosi don´t know if i explained this very good. hope you understand what i mean14:24
udonoTimitos: but there are problem on constraints. With a one table Version we need to maintain the ids in python, but that is bad, I think...14:25
Timitosudono: i don´t know if this is problematic. but this would have been also with the solution described from postgresql.14:27
Timitoscedk: your opinion to udonos msg?14:27
Timitosudono: cedk: i only try to find a solution with only one table. i had not the idea with to tables. i only think that we should discuss more than one idea because it is a tricky topic.14:29
Timitosso i will go on with my thoughts14:29
udonotimitos: yes14:30
cedkI agree with udono for the contsraint14:30
cedkwith one table, there will be I think many difficulty with constraint14:31
cedklike unique constraint that we use to check the integrity of the system14:31
TimitosACTION is thinking14:32
cedkand an other thing is the migration, if for a new version we add a new field that is required, we must fill all the historic data with  default value14:33
cedkinstead of just all active data14:33
cedkand one more, it is about delete record. If we use one table how do we now that a record is deleted14:34
cedkwe must delete all the history14:34
cedkbut with two table, we delete in the first table but keep the history in the second14:34
Timitoscedk: i think your idea is easier to implement. i will shut up :-)14:35
cedkTimitos: In fact, I have already seen this kind of implementation in a previous company where I work14:35
cedk:-)14:36
cedkbut it was using SQL trigger14:36
cedkand it was on oracle and I think there is a function to create a history table14:37
Timitoscedk: one question. how would you define an object as historic? do you define this in the object itself or would you define this in a realtion field ?  because you need to have a function to save a historic date for the relation field14:38
cedkOne thing, we need once we have historic object, is to be able to give on a many2one, many2many a date14:38
Timitosyes. i think this can be done within workflow in most cases14:39
cedkTimitos: I think that historic object must be create automicaly with one attributes on the object14:39
Timitoscedk: i agree14:40
cedkbut for the date to use in relation field, I'm not sure14:40
Timitoscedk: an idea...14:40
Timitoscedk: perhaps you can make an attribute on relation field like "historical=True/False"14:41
Timitosif it is true a date_field for the relation is created.14:41
cedkTimitos: yes but we need a date in fact14:41
Timitosbut there is another question.14:41
cedkI was thinking about give in argument the name of the date field to use14:42
Timitosdo we need to have a date field for every relation field or only for the complete record?14:42
cedklike 'create_date' or 'invoice_date' etc...14:42
Timitoscedk: good idea14:42
cedkTimitos: I think that the date must come from the record and not from the relation14:42
cedkand for many2one there is no relation table14:42
udonocedk: Timitos,  The best solution in my opinion would be one, where the framework maintain the history. A fields.* will be another internal  and external representation when it is historical or not.14:43
udono... but I know its hard to realize...14:43
Timitoscedk: i don´t understand completly14:43
cedkudono: I don't understand14:44
cedkTimitos: what?14:44
Timitoscedk: the date must come from the record?14:44
udonocedk: gimme a minute, I try to explain...14:45
cedkTimitos: ha, like for example the invoice: the date where the party must be read is the date of the invoice14:45
Timitosi think we should talk form table a and table b. perhaps we can understand each other better.14:45
Timitoscedk: ok. but...14:45
cedkTimitos: or object and historic object14:45
Timitoscedk: reverse14:46
Timitoscedk: i start again14:46
Timitoscedk: for invoice the date is clear14:46
Timitoscedk: all reation fields depend in history on the invoice date14:47
cedkTimitos: in fact I think it is more the date when we open the invoice14:47
Timitoscedk: but could it be that the relation field can have different historical dates? if this case can be then we need for every relation field a date_field14:48
Timitoscedk: yes. it is the date of opening the invoice14:48
cedkTimitos: yes, it will be like this: party = fields.Many2One('relationship.party', 'Party', history='invoice_date')14:48
cedkTimitos: so I think it need to be on each fields14:49
cedkudono: still don't understand your idea?14:50
Timitoscedk: on this way i can define in one object more different dates. great. perhaps we need this. but i don´t know a case yet.14:50
Timitoscedk: yes i think your idea is a great solution for the topic14:51
cedkTimitos: but there is some works :-)14:51
Timitoscedk: yes i know :-(14:51
-!- tekknokrat(n=gthieleb@port-87-193-170-219.static.qsc.de) has joined #tryton14:52
cedkTimitos: one more think we need, is a view to see all the history of a record14:52
Timitoscedk: is this a big problem? i think not14:53
cedkTimitos: no, but it can be well integrate in the client14:53
cedkTimitos: perhaps something like timemachine14:53
Timitosyou mean a widget?14:53
Timitostekknokrat: hi14:53
cedkhttp://www.apple.com/macosx/features/timemachine.html14:54
udonocedk: that I ment with internal and external representation... the external view could be an autogenerated view...14:54
cedkudono: what do you mean by external/internal14:55
tekknokrathi Timitos14:55
udonocedk: internal is the object structure for historical objects, external is the view of the historical datas to the user...14:55
udonohi tekknokrat14:55
Timitosudono: i don´t understand you too.14:56
tekknokrathi, udono14:56
cedkudono: ok, do you know timemachine?14:56
udonoIts the same direction cedk walk, I think, maybe just other words. We need to show how each field type of an object behave in historical context... this should be standardized. Than we can generate a automated view for the historical data...14:59
udonocedk: yes the concept sounds great. Its a mixture of historical immutability and revisioning system...15:00
cedkudono: we already have a automatic view generator15:00
Timitoscedk: what ideas do you have on this historic view?15:01
cedkTimitos: not yet really think15:01
cedkfirst think was to use the view of the object but it can be not enough15:02
udonocedk: yes, I know... but it would be great if we can implement historical data as transparent as possible. So we could autogenerate historical views on each object possible...15:02
cedkwe can have tree view, a list view order by date, the current form view of the object, and a default one that is constructed with all historical field15:02
Timitosperhaps we can first have a list with the revisions. then you can select the revision and see the content. but this can be done with the normal object view.15:03
udonocedk: yes, this could be the right way15:03
Timitoscedk: everything of your ideas sounds good to me.15:03
cedkor is it usefull to be able to see past record field that is no more used ?15:03
cedkor we can store the history of the view also, and use the one that match with the date15:04
cedkbut this case, you can see only one record per view15:05
udonocedk: yes, we have to pay attantion about the views... the historical datas need to fit into the view. So it could be the right way, to save the view with the data.15:06
cedkudono: not save the view with the data, but historised the ir.ui.view object :-)15:08
udonocedk: ok15:08
cedkjust a new thought, we need also duplicate relation table of a historised object15:09
cedklike the tables for many2many15:09
udonocedk: the object level history will be a big implementation... what about the smaller implementation of a just field level history for the first?15:11
udonocedk: about the last thought: yes, we need this if we like a real time machine. Than it could be possible to went back to an old date and show the complet system state this time...15:12
udonocedk: ... this will be the greatest, but most sophisticated...15:15
Timitoscedk: i vote for an easy version15:16
udonoTimitos: me too, I dont know if we are going to implement oracle into postgres :-)15:16
Timitos:-)15:17
Timitoscedk: do you think that what we discussed can be implemented or are there some bigger problems?15:18
udonoTimitos: on the other side I vote for an expandable small start version...15:19
Timitosudono: yes. but i think that the small solution cedk mentioned can be extended without problems.15:21
Timitoscedk: i think storing the history of the view is not needed in the first round.15:22
udonoTimitos: the Version cedk metioned is for me the big solution, I am looking for a smaller...15:22
udonocedk: how could the history table look like?15:23
udonocedk: is it possible to freeze tryton objects and put them into the db?15:23
Timitoscedk: with the historical solution we also can handle audit trail i think15:23
cedkudono: no, browse record are not really objects15:25
cedkudono: it is the DB record that have all the information15:25
cedkI think use historical object like I say will be not to complicate15:26
cedkbut need some times, especially for testing15:27
cedkhandling many2many history can be made later15:27
cedkand the view also, because generally we don't remove field but instead add15:27
cedkso having the last view will not be a problem15:28
Timitoscedk: +115:28
udonoTimitos: But for audittrail we need to save which actions are done by which user at a timestamp. But historical data may enrich the audittrail by the real changes...15:29
cedkudono: action will be the difference between two history records15:30
Timitosudono: yes i forgot actions that are not changes to a record15:30
cedkudono: and we can add the user name to the history table15:30
cedkTimitos: what action that doesn't change record ?15:30
udonocedk: yes, combining audittrail and history would be good.15:31
Timitoscedk: perhaps some workflow? perhaps? perhaps i am confused? :-)15:31
cedkTimitos: except printing reports, for me action means modify something15:32
Timitoscedk: yes. that´s right15:32
udonoTimitos: the audittrail is another approach, it needs to be plugged on the actions system in tryton and write down every action a user do. BTW. Printing an Report is an auditable action, too.15:33
cedkand if we need to store when user print report, it can be done15:33
cedkTimitos: we can add a logger in the service object that store all the calls15:34
Timitoscedk: that sounds great15:34
cedkbut I think it will be duplicate with the history objects15:35
udonocedk: but Audittrail is a general mechanism for all actions and history is just a partial mechnism for some tables?!15:36
Timitoscedk: only if the object has the historic attribute or would you define all tables with historic attribute?15:36
cedkyes, you are right15:37
cedkis it audit need to store reading action?15:37
udonocedk: If the chief like, it is audit to sore when you go make a coffee ;-)15:38
cedkudono: it needs big harddrives :-)15:38
udono:-)15:39
udonocedk: reading action means that someone open a record? Than yes.15:39
Timitosudono: this needs really big harddrives :-) i think audit trail for writing is enough for the beginning.15:40
cedkudono: this is easy, but the hard thing is to display to the user15:40
Timitosaudit trail for reading should pay a customer if he needs it.15:41
udonocedk, just name them like the action is called internal...15:41
cedkudono: yes, it is easy to store object, action, args in a table15:42
cedkudono: but it can slow down the system because of many table access15:42
udonocedk: like in the xmlrpc request. The easyest thing will be just to collect the actiondata from the xmlrpc...15:43
tekknokratmay i ask a question, how would you control if a view / object uses the historical data, e.g. for invoice reports15:43
cedkudono: that what I think15:44
cedktekknokrat: I don't understand your question15:44
udonocedk: the price you pay for auditing everything will be speed. I think its ok and normal.15:44
Timitoscedk: the admin should be able to set audition to some levels. off, write, write+read15:45
udonotekknokrat: ced proposed a flag like _history= True in the Object.15:46
Timitostekknokrat: example invoice: you have a invoice date. if this is set, then the historic data is used. if it is not set. the actual data is used.15:46
tekknokratudono: ah ok thats what i mean15:46
Timitostekknokrat: it will be like this: party = fields.Many2One('relationship.party', 'Party', history='invoice_date')15:47
tekknokratTimitos: ok, will this be a configurable option in general, or only apply to some objects where it fit the business case?15:48
cedktekknokrat: it will depend of the developer, but it will be easy to create module that add history on some objects15:50
udonocedk: back to historical data: I think we dont need timemachine behaviour for the first. Realy needed is the integrity of datachanges over time, because this is a governmental requirement. Maybe we dont need any views about the history in the first implementation.15:50
tekknokratcedk: sounds like a good idea only extending the api a bit and let module-developer decide!15:51
cedkudono: yes, it can be done in two or three steps15:51
udonoTimitos: did you know if the invoice template needs to be revisioned, too?15:52
Timitosudono: you are right. the invoice template needs to be revisioned too.15:55
cedkthe template? we already store the invoice in the DB.15:55
udonocedk: the compleat pdf? or the data only?15:56
Timitoscedk: yes i forgot. thats enough.15:56
cedkudono: the complet pdf or odt15:56
cedkand know also the format :-)15:57
Timitosthe law says, that the records must be hold in an analysable format...15:57
Timitosand the report must be hold in its original15:57
udonocedk: oh, I didnt recognized this :-)15:57
Timitosthere ist no demand to do this together15:58
Timitosgreat discussion today!15:59
cedkudono: by the way, can we start including the german translation ?15:59
udonocedk: Fwiesinger did the translation into the roundup but htgoebel had some changes mentioned. So I would say, just wait. Maybe untill next week on thursday. So everyone may take a look if the translation is ok. I didnt look inside for now. This week is impossible for me, sorry, I have this plone job to do, but maybe next week I will help more.16:05
udonohtgoebel=essich16:05
udonoafk for short16:06
cedkok16:09
udonoback16:10
udonoBTW about translation: I thik around to make the translation process more collaborative. So we all have this google login, we could use google database for the translation tables. A tryton module can import the translations from there. So everyone with a google login could contribute translations...16:13
udonoand as a benefit no one of the devels is needed for this to implement translations...16:14
udono... another possibility is the use of google spreatsheets, than google database...16:17
udono... http://www.youtube.com/watch?v=rWCLROPKug016:20
-!- tekknokrat(n=gthieleb@port-87-193-170-219.static.qsc.de) has left #tryton16:33
-!- kultviech(n=kultviec@p5497632C.dip.t-dialin.net) has joined #tryton16:33
Timitoskultviech: hallo16:34
-!- tekknokrat(n=gthieleb@port-87-193-170-219.static.qsc.de) has joined #tryton16:34
kultviechhi Timitos16:35
udonokultviech: hi16:44
cedkudono: I think this is now complicate because it is not in the repository but once it is in the repo, we will work only with patches and it will be easier16:47
udonocedk: yes, the google thing is fo the next year....16:47
tekknokratbye, everybody17:04
tekknokrat/quit17:05
-!- tekknokrat(n=gthieleb@port-87-193-170-219.static.qsc.de) has left #tryton17:05
-!- Timitos(n=Timitos@88.217.184.172) has left #tryton18:12
-!- Timitos(n=Timitos@88.217.184.172) has joined #tryton18:12
-!- FWiesing(n=FWiesing@194.208.185.12) has joined #tryton19:48
FWiesinggood evening19:49
TimitosFWiesing: hi19:50
-!- kultviech(n=kultviec@p5497632C.dip.t-dialin.net) has left #tryton20:07
-!- Timitos(n=Timitos@88.217.184.172) has left #tryton21:19
-!- Timitos(n=kp@88.217.184.172) has joined #tryton21:20
-!- tekknokrat(n=gthieleb@dslb-088-075-236-077.pools.arcor-ip.net) has joined #tryton23:36
-!- tekknokrat(n=gthieleb@dslb-088-075-236-077.pools.arcor-ip.net) has left #tryton23:37

Generated by irclog2html.py 2.11.0 by Marius Gedminas - find it at mg.pov.lt!