| chat.freenode.net #tryton log beginning Sat Jan 25 00:00:01 CET 2014 | ||
| 2014-01-25 00:05 <cedk> hellhound: how does supervisor shut the process? | ||
| 2014-01-25 00:06 <hellhound> cedk: either sending a TERM or KILL, it's configurable | ||
| 2014-01-25 00:06 <hellhound> cedk: TERM by default | ||
| 2014-01-25 00:07 <hellhound> cedk: it's possible that supervisor doesn't give it sufficient time to shut down properly | ||
| 2014-01-25 00:08 <cedk> hellhound: trytond waits that all thread finish | ||
| 2014-01-25 00:10 <hellhound> cedk: how long do you think I'd should wait before it shuts down properly? | ||
| 2014-01-25 00:10 <hellhound> cedk: 5 seconds? | ||
| 2014-01-25 00:13 <cedk> hellhound: can't say it depends of the running requests | ||
| 2014-01-25 00:14 <hellhound> cedk: yeah, that's true, but if I had to throw a figure, 10 or maybe 20 seconds? | ||
| 2014-01-25 00:15 <hellhound> cedk: tryton doesn't have a way to signal when it shuts down? | ||
| 2014-01-25 00:16 <hellhound> cedk: maybe by scraping it's output | ||
| 2014-01-25 00:16 <hellhound> :P | ||
| 2014-01-25 00:16 <cedk> hellhound: it never shutdowns on his own | ||
| 2014-01-25 00:17 <hellhound> cedk: that's why I send it a TERM signal | ||
| 2014-01-25 00:18 <cedk> hellhound: so no need to tell you that you send a signal | ||
| 2014-01-25 00:18 <hellhound> cedk: I believe that's the way normal *nix processes know when to shut down | ||
| 2014-01-25 00:19 <hellhound> cedk: thanks anyways, I'd figure out a solution | ||
| 2014-01-25 00:20 <hellhound> *I'll | ||
| 2014-01-25 02:55 -!- hellhound(~hellhound@unaffiliated/hellhound) has left #tryton | ||
| 2014-01-25 17:37 <dada-p> hello, I have a question re: client and default properties | ||
| 2014-01-25 17:38 <dada-p> how would I setup default country for new parties? | ||
| 2014-01-25 17:39 <cedk> dada-p: write a module and define a default method | ||
| 2014-01-25 17:44 <dada-p> can I change it through configuration->model->default properties? | ||
| 2014-01-25 17:45 <cedk> dada-p: no it is not a property | ||
| 2014-01-25 17:46 <dada-p> but that is form's default value? at least in openerp was like this... | ||
| 2014-01-25 17:47 <cedk> dada-p: this was removed because it is a buggy concept leading to many issues | ||
| 2014-01-25 17:50 <cedk> http://hg.tryton.org/trytond/rev/7596b2af1c55 | ||
| 2014-01-25 17:51 <dada-p> ic... ok, thanks. so changing the model through the code is the only way.. secure, but not fast | ||
| 2014-01-25 17:53 <cedk> dada-p: yes it is secure, testable, reproducible… | ||
| 2014-01-25 17:56 <dada-p> usability-wise it is not flexible though - especially when different users need different sets of values (personal customization) | ||
| 2014-01-25 17:58 <cedk> dada-p: is it really usability when the software is completly broken? | ||
| 2014-01-25 17:58 <dada-p> well, is a good program when nobody except developer can work in it? =) | ||
| 2014-01-25 17:59 <cedk> dada-p: if you think it is using it, well… | ||
| 2014-01-25 18:14 <cedk> dada-p: if you can provide a design in which users can not break the application, it will be welcomed | ||
| 2014-01-25 18:20 <dada-p> cedk: 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. | ||
| 2014-01-25 18:21 <cedk> dada-p: even conceptually | ||
| 2014-01-25 18:25 <dada-p> well, 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. | ||
| 2014-01-25 18:27 <dada-p> it can be also done through permissions - if underlying mechanism allow to set perms on model's fields | ||
| 2014-01-25 18:33 <dada-p> permissions 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. | ||
| 2014-01-25 18:45 <cedk> dada-p: all that is already in Tryton | ||
| 2014-01-25 18:47 <dada-p> but there is no end-user access to those settings? like if I want to have address default country different for two different users? | ||
| 2014-01-25 19:23 <cedk> dada-p: in your description, you don't talk about default values | ||
| 2014-01-25 19:25 -!- Telesight(~anthony@77-175-168-222.FTTH.ispfabriek.nl) has left #tryton | ||
| 2014-01-25 19:26 <cedk> dada-p: by the way, we have some default value defined in config Models | ||
| 2014-01-25 19:26 <cedk> dada-p: but we put only the ones that are needed by the large number | ||
| 2014-01-25 19:27 <cedk> dada-p: people are free to implement modules to add more | ||
| 2014-01-25 19:32 <dada-p> cedk: 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... | ||
| 2014-01-25 19:33 <cedk> dada-p: yes, it was so often that users screw up everything with that | ||
| 2014-01-25 19:35 <dada-p> if 1) was a reason - that can be fixed by introducing an attribute 'changeable' to the field. if 2) - then there was a big problem | ||
| 2014-01-25 19:36 <cedk> dada-p: https://groups.google.com/forum/#!searchin/tryton-dev/ir.default/tryton-dev/pMa0SKKITxk/slEgH46QzLIJ | ||
| 2014-01-25 19:37 <cedk> dada-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 modularity | ||
| 2014-01-25 19:38 <cedk> dada-p: to summaryze only a dev can tell if it is possible or not depending of the modules installed | ||
| 2014-01-25 19:49 <hellhound> cedk: hey, remember last time we talk about separating data by company? | ||
| 2014-01-25 19:50 <dada-p> cedk: 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... | ||
| 2014-01-25 19:50 <hellhound> cedk: so, the only way to accomplish this is by using different databases? | ||
| 2014-01-25 19:50 <hellhound> cedk: I mean, not only separating data but visibility too | ||
| 2014-01-25 19:51 <cedk> hellhound: no, I said there are 2 possibilities but the all in one database is complex to setup and should really be needed and valuable | ||
| 2014-01-25 19:52 <cedk> dada-p: it was implemented for each cases identified | ||
| 2014-01-25 19:52 <cedk> dada-p: the example about the invoice method on sale is implemented | ||
| 2014-01-25 19:52 <cedk> dada-p: and many others, just look at the config folder of each area | ||
| 2014-01-25 19:52 <hellhound> cedk: in which case, how can I setup an all-in-one db? | ||
| 2014-01-25 19:53 <cedk> hellhound: it is a analysis to be done case by case, there are no rules | ||
| 2014-01-25 19:53 <hellhound> configuration-wise should be more easy to maintain... | ||
| 2014-01-25 19:53 <hellhound> hmm I see | ||
| 2014-01-25 19:53 <cedk> hellhound: and it is an implementation strategy | ||
| 2014-01-25 19:58 <dada-p> cedk: 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? | ||
| 2014-01-25 20:08 <cedk> dada-p: yes | ||
| 2014-01-25 20:09 <dada-p> I 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... | ||
| 2014-01-25 20:10 <cedk> dada-p: you can just put a link to user | ||
| 2014-01-25 20:12 <dada-p> cedk: i'm talking not about accessibility of setting but separation: each user has its own value. | ||
| 2014-01-25 20:13 <cedk> dada-p: yes a link to user to separate | ||
| 2014-01-25 20:14 <dada-p> cedk: elaborate please, not getting it... | ||
| 2014-01-25 20:15 <cedk> dada-p: on the model where you want to store such default value adds a link to user | ||
| 2014-01-25 20:18 <dada-p> what 'link' here stands for? action/menu? any module with such example? | ||
| 2014-01-25 20:21 <cedk> dada-p: many2one | ||
| 2014-01-25 20:29 <dada-p> cedk: still difficult to get it. I understand what you are meaning but somehow not sure that it will work =) any known example perhaps? | ||
| 2014-01-25 20:30 <cedk> dada-p: not existing base on user | ||
| 2014-01-25 20:36 <cedk> dada-p: http://dpaste.com/1569156/ | ||
| 2014-01-25 20:37 <dada-p> cedk: that's much better, thanks! =) | ||
| 2014-01-25 20:38 <cedk> dada-p: better: http://dpaste.com/1569159/ | ||
| 2014-01-25 21:52 -!- hellhound(~hellhound@unaffiliated/hellhound) has left #tryton |
Generated by irclog2html.py 2.17.3 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!