IRC logs of #tryton for Saturday, 2014-01-25 #tryton log beginning Sat Jan 25 00:00:01 CET 2014
cedkhellhound: how does supervisor shut the process?00:05
hellhoundcedk: either sending a TERM or KILL, it's configurable00:06
hellhoundcedk: TERM by default00:06
hellhoundcedk: it's possible that supervisor doesn't give it sufficient time to shut down properly00:07
cedkhellhound: trytond waits that all thread finish00:08
hellhoundcedk: how long do you think I'd should wait before it shuts down properly?00:10
hellhoundcedk: 5 seconds?00:10
cedkhellhound: can't say it depends of the running requests00:13
hellhoundcedk: yeah, that's true, but if I had to throw a figure, 10 or maybe 20 seconds?00:14
hellhoundcedk: tryton doesn't have a way to signal when it shuts down?00:15
hellhoundcedk: maybe by scraping it's output00:16
cedkhellhound: it never shutdowns on his own00:16
hellhoundcedk: that's why I send it a TERM signal00:17
cedkhellhound: so no need to tell you that you send a signal00:18
hellhoundcedk: I believe that's the way normal *nix processes know when to shut down00:18
hellhoundcedk: thanks anyways, I'd figure out a solution00:19
-!- hellhound(~hellhound@unaffiliated/hellhound) has left #tryton02:55
dada-phello, I have a question re: client and default properties17:37
dada-phow would I setup default country for new parties?17:38
cedkdada-p: write a module and define a default method17:39
dada-pcan I change it through configuration->model->default properties?17:44
cedkdada-p: no it is not a property17:45
dada-pbut that is form's default value? at least in openerp was like this...17:46
cedkdada-p: this was removed because it is a buggy concept leading to many issues17:47
dada-pic... ok, thanks. so changing the model through the code is the only way.. secure, but not fast17:51
cedkdada-p: yes it is secure, testable, reproducible…17:53
dada-pusability-wise it is not flexible though - especially when different users need different sets of values (personal customization)17:56
cedkdada-p: is it really usability when the software is completly broken?17:58
dada-pwell, is a good program when nobody except developer can work in it? =)17:58
cedkdada-p: if you think it is using it, well…17:59
cedkdada-p: if you can provide a design in which users can not break the application, it will be welcomed18:14
dada-pcedk: I'm at a beginning of study tryton's architecture, I had only openerp experience so far. conceptually I can tell but how to implement that I don't know yet.18:20
cedkdada-p: even conceptually18:21
dada-pwell, the idea is to separate application data (both meta and installation, such as precision, account/tax etc) from user data (tz, language, soft defaults for forms - addresses, invoice terms, etc). i guess one would need to store them separately.18:25
dada-pit can be also done through permissions - if underlying mechanism allow to set perms on model's fields18:27
dada-ppermissions gives much more flexibility when deciding what user can change and what - not. downside can be speed, i guess - additional checks would slow down processing.18:33
cedkdada-p: all that is already in Tryton18:45
dada-pbut there is no end-user access to those settings? like if I want to have address default country different for two different users?18:47
cedkdada-p: in your description, you don't talk about default values19:23
-!- Telesight( has left #tryton19:25
cedkdada-p: by the way, we have some default value defined in config Models19:26
cedkdada-p: but we put only the ones that are needed by the large number19:26
cedkdada-p: people are free to implement modules to add more19:27
dada-pcedk: if you remember, old gtk client of openerp had that action on form - 'save defaults..' where user could choose what to store. if I understand you correctly, that behaviour was not right either because 1) user could override really important values or 2) it was stored improperly? sorry, there is no bug attached to the changeset you mention, so I can't see what was the reason...19:32
cedkdada-p: yes, it was so often that users screw up everything with that19:33
dada-pif 1) was a reason - that can be fixed by introducing an attribute 'changeable' to the field. if 2) - then there was a big problem19:35
cedkdada-p: changeable attribute is not a good solution because it depends on so much paramteters and it is impossible to know it because of the modularity19:37
cedkdada-p: to summaryze only a dev can tell if it is possible or not depending of the modules installed19:38
hellhoundcedk: hey, remember last time we talk about separating data by company?19:49
dada-pcedk: ok, I can see that previous discussion end up without much conclusion. But I can see now the reasons why it was dangerous as it was implemented. There was nice idea about three-tier defaults: system-company-user but it was never implemented I guess... You are right, system and even company (less flexible though) can be defined by the module, but user's one...19:50
hellhoundcedk: so, the only way to accomplish this is by using different databases?19:50
hellhoundcedk: I mean, not only separating data but visibility too19:50
cedkhellhound: no, I said there are 2 possibilities but the all in one database is complex to setup and should really be needed and valuable19:51
cedkdada-p: it was implemented for each cases identified19:52
cedkdada-p: the example about the invoice method on sale is implemented19:52
cedkdada-p: and many others, just look at the config folder of each area19:52
hellhoundcedk: in which case, how can I setup an all-in-one db?19:52
cedkhellhound: it is a analysis to be done case by case, there are no rules19:53
hellhoundconfiguration-wise should be more easy to maintain...19:53
hellhoundhmm I see19:53
cedkhellhound: and it is an implementation strategy19:53
dada-pcedk: you are saying that the same approach can be applied to party module and user's default config should be located in 'Party configuration'? But as it is not a popular demand it would be left to developer to implement it in each separate case?19:58
cedkdada-p: yes20:08
dada-pI can agree with a location and way of changing (UI part), but can't see how is it possible to implement it user-wise (architecture and model part), except extending res.user? But then again is a problem to evaluate stored value...20:09
cedkdada-p: you can just put a link to user20:10
dada-pcedk: i'm talking not about accessibility of setting but separation: each user has its own value.20:12
cedkdada-p: yes a link to user to separate20:13
dada-pcedk: elaborate please, not getting it...20:14
cedkdada-p: on the model where you want to store such default value adds a link to user20:15
dada-pwhat 'link' here stands for? action/menu? any module with such example?20:18
cedkdada-p: many2one20:21
dada-pcedk: still difficult to get it. I understand what you are meaning but somehow not sure that it will work =) any known example perhaps?20:29
cedkdada-p: not existing base on user20:30
dada-pcedk: that's much better, thanks! =)20:37
cedkdada-p: better:
-!- hellhound(~hellhound@unaffiliated/hellhound) has left #tryton21:52

Generated by 2.11.0 by Marius Gedminas - find it at!