| chat.freenode.net #tryton log beginning Tue Jul 14 00:00:03 CEST 2015 | ||
| 2015-07-14 00:29 -!- smarro(~sebastian@190.105.68.82) has joined #tryton | ||
| 2015-07-14 00:58 -!- jcnorman(~jcnorman@24-197-138-90.dhcp.spbg.sc.charter.com) has joined #tryton | ||
| 2015-07-14 01:14 -!- jcnorman(~jcnorman@24-197-138-90.dhcp.spbg.sc.charter.com) has joined #tryton | ||
| 2015-07-14 01:30 -!- jcnorman(~jcnorman@24-197-138-90.dhcp.spbg.sc.charter.com) has joined #tryton | ||
| 2015-07-14 01:37 -!- smarro(~sebastian@190.105.93.196) has joined #tryton | ||
| 2015-07-14 02:16 -!- pablovannini(~pablo@186.18.46.165) has joined #tryton | ||
| 2015-07-14 06:40 -!- frispete(~frispete@p54A90010.dip0.t-ipconnect.de) has joined #tryton | ||
| 2015-07-14 06:43 -!- udono(~udono@ip-178-202-238-79.hsi09.unitymediagroup.de) has joined #tryton | ||
| 2015-07-14 06:55 -!- VaticanCameos(~pritishc@182.68.223.3) has joined #tryton | ||
| 2015-07-14 06:59 -!- LordVan(~LordVan@gentoo/developer/LordVan) has joined #tryton | ||
| 2015-07-14 07:01 -!- yangoon(~mathiasb@p549F1961.dip0.t-ipconnect.de) has joined #tryton | ||
| 2015-07-14 07:58 -!- Telesight(~anthony@4dafe0c0.ftth.telfortglasvezel.nl) has joined #tryton | ||
| 2015-07-14 08:17 -!- digitalsatori(~Thunderbi@125.7.119.155) has joined #tryton | ||
| 2015-07-14 08:30 -!- digitalsatori(~Thunderbi@125.7.119.155) has joined #tryton | ||
| 2015-07-14 08:38 -!- digitalsatori(~Thunderbi@125.7.119.155) has joined #tryton | ||
| 2015-07-14 08:42 -!- rpit(~rpit@2a02:908:e670:6ac0:1425:148d:949:6c88) has joined #tryton | ||
| 2015-07-14 08:50 -!- cedk(~ced@gentoo/developer/cedk) has joined #tryton | ||
| 2015-07-14 09:05 -!- VaticanCameos(~pritishc@182.68.223.3) has joined #tryton | ||
| 2015-07-14 09:09 -!- digitalsatori(~Thunderbi@125.7.119.155) has joined #tryton | ||
| 2015-07-14 09:11 -!- digitalsatori(~Thunderbi@125.7.119.155) has joined #tryton | ||
| 2015-07-14 09:21 -!- pokoli(~pokoli@unaffiliated/pokoli) has joined #tryton | ||
| 2015-07-14 09:45 -!- michael-kohlhaas(~michael-k@unaffiliated/michael-kohlhaas) has joined #tryton | ||
| 2015-07-14 10:14 -!- digitalsatori(~Thunderbi@125.7.119.155) has joined #tryton | ||
| 2015-07-14 10:31 -!- nicoe(~nicoe@balisto.wifi.b2ck.com) has joined #tryton | ||
| 2015-07-14 10:42 -!- Telesight(~anthony@4dafe0c0.ftth.telfortglasvezel.nl) has joined #tryton | ||
| 2015-07-14 10:49 -!- Telesight(~anthony@4dafe0c0.ftth.telfortglasvezel.nl) has joined #tryton | ||
| 2015-07-14 11:06 -!- VaticanCameos(~pritishc@182.68.223.3) has joined #tryton | ||
| 2015-07-14 11:29 -!- Telesight(~anthony@4dafe0c0.ftth.telfortglasvezel.nl) has joined #tryton | ||
| 2015-07-14 12:05 -!- Telesight(~anthony@4dafe0c0.ftth.telfortglasvezel.nl) has joined #tryton | ||
| 2015-07-14 13:10 -!- mariomop(~quassel@host123.190-138-108.telecom.net.ar) has joined #tryton | ||
| 2015-07-14 13:31 -!- Telesight(~anthony@4dafe0c0.ftth.telfortglasvezel.nl) has joined #tryton | ||
| 2015-07-14 13:44 -!- cinik(~smilicic@cpe-188-252-142-163.zg5.cable.xnet.hr) has joined #tryton | ||
| 2015-07-14 13:44 <cinik> Hello! | ||
| 2015-07-14 13:46 <cinik> I have a question - someone may be able to help me; I'm porting my own modules from tryton 3.4 to tryton 3.6, but I have problems with json in form->group->states attributes. | ||
| 2015-07-14 13:51 <cinik> Sorry - had some nickname issues | ||
| 2015-07-14 13:52 <cinik> Anyway, I'm porting my old states="{'invisbile': Bool(Not(Equal(Eval('type_'),'N')))}" to something, and I get either of the following errors: | ||
| 2015-07-14 13:53 <cinik> if I use proper JSON, {"invisble": "Eval(\"type_\") != \"N\" "}, then PYSON complains of getting a string. | ||
| 2015-07-14 13:53 <cinik> if I skip the quotes, JSON complains about syntax errors | ||
| 2015-07-14 13:54 <cinik> this happens both with stock json and simplejson | ||
| 2015-07-14 13:54 <cinik> please help me :) | ||
| 2015-07-14 13:55 -!- kstenger(~karla@200.124.209.158) has joined #tryton | ||
| 2015-07-14 14:10 -!- rpit(~rpit@2a02:908:e670:6ac0:e037:d91f:e8bb:3f2e) has joined #tryton | ||
| 2015-07-14 14:21 <cedk> cinik: the simpliest is to use http://doc.tryton.org/3.6/trytond/doc/ref/models/models.html?highlight=view_attribute#trytond.model.ModelView.view_attributes | ||
| 2015-07-14 14:43 -!- juanfe(~juanfe@190.85.115.49) has joined #tryton | ||
| 2015-07-14 15:04 -!- jcnorman(~jcnorman@24-197-138-90.dhcp.spbg.sc.charter.com) has joined #tryton | ||
| 2015-07-14 15:08 -!- jcnorman_(~jcnorman@24-197-138-90.dhcp.spbg.sc.charter.com) has joined #tryton | ||
| 2015-07-14 15:33 -!- bvillasanti(~bvillasan@181.16.21.34) has joined #tryton | ||
| 2015-07-14 15:36 -!- nicoe(~nicoe@ptr-178-50-65-110.dyn.mobistar.be) has joined #tryton | ||
| 2015-07-14 15:43 -!- smarro(~sebastian@181.192.57.21) has joined #tryton | ||
| 2015-07-14 16:03 -!- nicoe(~nicoe@82-212-130-50.teledisnet.be) has joined #tryton | ||
| 2015-07-14 16:10 <cinik> cedk: thanks ... I didn't find it obvious from the documentation; quite the opposite, as the docs say "PYSON string" for the state attribute, I kept repeatedly shoving PYSON down in XML and hoping for a different result. :) | ||
| 2015-07-14 16:13 <cinik> One more thing I'im interested - a some what philosophical/UX question: ModelSingleton (and similar concepts) rely on default_get, which in the client is automatically regarded as changed without saving; so if you open a singleton form just to check something, it asks you to save changes. That is very confusing and annoying. Is there a way around that? | ||
| 2015-07-14 16:13 <cedk> cinik: don't understand what is wrong with "PYSON string" | ||
| 2015-07-14 16:14 <cedk> cinik: no | ||
| 2015-07-14 16:14 <cedk> cinik: but patch is welcomed | ||
| 2015-07-14 16:15 <cinik> cedk: the problem is that it's not obvious from the docs that you have to put xml attributes in the python code when doing what I wanted to do... | ||
| 2015-07-14 16:16 <cedk> cinik: you are not required to do so | ||
| 2015-07-14 16:16 <cedk> cinik: you can put a PYSON string | ||
| 2015-07-14 16:18 <cinik> I tried, but it wouldn't evaluate (my original question: either it fails as JSON or it fails as PYSON) | ||
| 2015-07-14 16:19 <cedk> cinik: it works, you probably did not correctly encoded in the XML | ||
| 2015-07-14 16:19 <cedk> cinik: that's why the ModelView.view_attributes is simplier because it does the job correctly | ||
| 2015-07-14 16:21 <cinik> cedk: yup, but the docs don't hint that at all, and also they don't give an example of xml-embedded PYSON for 3.6 (it worked for 3.4) | ||
| 2015-07-14 16:22 <cedk> cinik: patch is welcome | ||
| 2015-07-14 16:22 <cinik> cedk: I'll try to get around to it | ||
| 2015-07-14 16:24 <cinik> cedk: also, for the singleton issue, I am afraid that it would require patching the protocol on both sides (something on the lines of a ModelView.default_record method that the client would ask for first). | ||
| 2015-07-14 16:24 <cinik> cedk: what I wonder is how much that would be against some tryton metapriciple | ||
| 2015-07-14 16:25 <cedk> cinik: don't understand | ||
| 2015-07-14 16:28 <cinik> cedk: as far as I see it, if the client opens a form for a model not from a tree view, it automatically assumes creating a new object and calls ModelView.default_get... patching that would require patching the protocol on the client side and adding a method on the server side. I wonder if there is something inherently untrytonic (analogous to unpythonic) in doing that. | ||
| 2015-07-14 16:35 <cedk> cinik: ModelSingleton should not be a special case | ||
| 2015-07-14 16:47 <cinik> cedk: I completly agree - that's why I'm looking into a more general fix - suppose we add to ModelView a method called default_record that retruns a single record id or None so that every time a client opens a form directly from an action (not from a tree view), it first asks for default_record, and if it gets None, it goes to ModelView.default_get, otherwise it goes to read the record. | ||
| 2015-07-14 16:48 <cedk> cinik: I don't see the logical for such call | ||
| 2015-07-14 17:00 <cinik> cedk: currently, when the client is to open a form without any prior information (eg. the default action in the main menu opens a form), the client calls assumes the user wants to create a new record. Right? | ||
| 2015-07-14 17:01 <cinik> cedk: sorry, should have been "the client calls model.default_get assuming the user wants to create a new record" | ||
| 2015-07-14 17:08 -!- bvillasanti(~bvillasan@181.16.21.34) has joined #tryton | ||
| 2015-07-14 17:10 <cedk> cinik: yes but it normal to call default_get when creating a record | ||
| 2015-07-14 17:15 <cinik> cedk: of course it is, but my point given no prior information, the client, whent asked to open a form, assumes the user wants to create a new form | ||
| 2015-07-14 17:16 <cinik> cedk: that assumption fails for the singleton (naturally), and could possibly fail for some other conecpts (for example a model for user's own settings and information) | ||
| 2015-07-14 17:16 <cinik> (sorry, that should have been "assumes the user wants to create a new record") | ||
| 2015-07-14 17:19 <cedk> cinik: but a singleton doesn't necessary exist prior | ||
| 2015-07-14 17:21 <cinik> cedk: sure it doesn't - but the client should check first for a default record, and only if none is found should it attempt to create one | ||
| 2015-07-14 17:23 <cedk> cinik: I don't agree because it leads to ackward behaviour | ||
| 2015-07-14 17:23 <cedk> cinik: what if there is more than 1 record? Which one is shown? | ||
| 2015-07-14 17:24 <cinik> cedk: the model is to answer which one should it regard as the default. I think the method should live in the ModelStorage class, returning by default None | ||
| 2015-07-14 17:25 <cedk> cinik: don't understand | ||
| 2015-07-14 17:25 <cinik> cedk: then, for example, if you implement a UserSettings model for some use, you want the user to be able to edit only their own settings, and the method should return the user id as the default record | ||
| 2015-07-14 17:25 <cedk> cinik: I don't understand what you mean by "default" | ||
| 2015-07-14 17:25 <cedk> cinik: I don't see any generic behaviour in your examples | ||
| 2015-07-14 17:27 <cinik> cedk: the behaviour of the client is if you open a form and there's no record selected, create a new one, right? | ||
| 2015-07-14 17:29 <cedk> cinik: what do you mean by "record selected"? | ||
| 2015-07-14 17:31 <cinik> cedk: if the form view has a lower sequence number than the tree view, and you open that view, then the client automatically goes for default_get to create a new record | ||
| 2015-07-14 17:32 <cedk> cinik: not necessary | ||
| 2015-07-14 17:32 <cedk> cinik: it depends of the action | ||
| 2015-07-14 17:32 <cinik> cedk: how? | ||
| 2015-07-14 17:33 <cedk> cinik: look at the code | ||
| 2015-07-14 17:46 -!- digitalsatori(~Thunderbi@203.35.234.18) has joined #tryton | ||
| 2015-07-14 17:48 <cinik> cedk: if res_id for a Form is not set in the client, it goes for a new record; I'm proposing that if res_id is not set and the view_type is form to first ask for something like common.MODELACCESS[self.model]['default-record'] and if that fails (returns None or False), goes for sig_new | ||
| 2015-07-14 17:48 <cinik> cedk: (thanks for making me find my way through the client code - I've been dreading that up until now :) ) | ||
| 2015-07-14 17:50 <cedk> cinik: I don't see the point to add an extra call while res_id is already doing the job | ||
| 2015-07-14 17:52 <cinik> cedk: Actually it's not - if it is not set, it resorts to creating a record; I think it's up to the server (i.e. the model) to decide what to do when a form is opened without res_id being set. | ||
| 2015-07-14 17:54 <cedk> cinik: no it is create a double specs | ||
| 2015-07-14 17:55 <cinik> cedk: sorry, I didn't understand that | ||
| 2015-07-14 17:55 <cedk> cinik: there is already a parameter to do what you want: res_id | ||
| 2015-07-14 18:16 <cedk> cinik: probably a solution will be to have a generic wizard that returns the right action (with res_id filled) to use on any singleton | ||
| 2015-07-14 18:34 -!- kstenger(~karla@200.124.209.158) has joined #tryton | ||
| 2015-07-14 19:03 -!- jcnorman(~jcnorman@24-197-138-90.dhcp.spbg.sc.charter.com) has joined #tryton | ||
| 2015-07-14 19:58 -!- sunny_dealmeida(~quassel@203.115.83.43) has joined #tryton | ||
| 2015-07-14 20:15 -!- cinik(~smilicic@cpe-188-252-142-163.zg5.cable.xnet.hr) has joined #tryton | ||
| 2015-07-14 20:25 -!- rainer_s1nstwo(~rainer@pd956864b.dip0.t-ipconnect.de) has joined #tryton | ||
| 2015-07-14 21:36 -!- FvD(~Thunderbi@ip95-153-64-186.ct.co.cr) has joined #tryton | ||
| 2015-07-14 21:37 -!- FvD(~Thunderbi@ip95-153-64-186.ct.co.cr) has joined #tryton | ||
| 2015-07-14 21:40 -!- smarro(~sebastian@181.192.57.21) has joined #tryton | ||
| 2015-07-14 21:51 -!- pokoli(~pokoli@unaffiliated/pokoli) has joined #tryton | ||
| 2015-07-14 22:03 -!- michael-kohlhaas(~michael-k@unaffiliated/michael-kohlhaas) has joined #tryton | ||
| 2015-07-14 22:07 -!- FvD(~Thunderbi@ip95-153-64-186.ct.co.cr) has joined #tryton | ||
| 2015-07-14 22:17 -!- FvD(~Thunderbi@ip95-153-64-186.ct.co.cr) has joined #tryton | ||
| 2015-07-14 22:21 -!- pokoli(~pokoli@unaffiliated/pokoli) has joined #tryton | ||
| 2015-07-14 22:24 -!- nineinchnick(~jwas@109.231.22.187) has joined #tryton | ||
| 2015-07-14 22:29 -!- smarro(~sebastian@181.192.57.21) has joined #tryton | ||
| 2015-07-14 22:30 -!- FvD(~Thunderbi@ip95-153-64-186.ct.co.cr) has joined #tryton | ||
| 2015-07-14 23:28 -!- alimon(alimon@nat/intel/x-gnneymyqpexanntb) has joined #tryton | ||
| 2015-07-14 23:47 -!- smarro(~sebastian@181.192.57.21) has joined #tryton | ||
| 2015-07-14 23:52 -!- jcnorman(~jcnorman@24-197-138-90.dhcp.spbg.sc.charter.com) has joined #tryton |
Generated by irclog2html.py 2.17.3 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!