IRC logs of #tryton for Tuesday, 2015-07-14

chat.freenode.net #tryton log beginning Tue Jul 14 00:00:03 CEST 2015
-!- smarro(~sebastian@190.105.68.82) has joined #tryton00:29
-!- jcnorman(~jcnorman@24-197-138-90.dhcp.spbg.sc.charter.com) has joined #tryton00:58
-!- jcnorman(~jcnorman@24-197-138-90.dhcp.spbg.sc.charter.com) has joined #tryton01:14
-!- jcnorman(~jcnorman@24-197-138-90.dhcp.spbg.sc.charter.com) has joined #tryton01:30
-!- smarro(~sebastian@190.105.93.196) has joined #tryton01:37
-!- pablovannini(~pablo@186.18.46.165) has joined #tryton02:16
-!- frispete(~frispete@p54A90010.dip0.t-ipconnect.de) has joined #tryton06:40
-!- udono(~udono@ip-178-202-238-79.hsi09.unitymediagroup.de) has joined #tryton06:43
-!- VaticanCameos(~pritishc@182.68.223.3) has joined #tryton06:55
-!- LordVan(~LordVan@gentoo/developer/LordVan) has joined #tryton06:59
-!- yangoon(~mathiasb@p549F1961.dip0.t-ipconnect.de) has joined #tryton07:01
-!- Telesight(~anthony@4dafe0c0.ftth.telfortglasvezel.nl) has joined #tryton07:58
-!- digitalsatori(~Thunderbi@125.7.119.155) has joined #tryton08:17
-!- digitalsatori(~Thunderbi@125.7.119.155) has joined #tryton08:30
-!- digitalsatori(~Thunderbi@125.7.119.155) has joined #tryton08:38
-!- rpit(~rpit@2a02:908:e670:6ac0:1425:148d:949:6c88) has joined #tryton08:42
-!- cedk(~ced@gentoo/developer/cedk) has joined #tryton08:50
-!- VaticanCameos(~pritishc@182.68.223.3) has joined #tryton09:05
-!- digitalsatori(~Thunderbi@125.7.119.155) has joined #tryton09:09
-!- digitalsatori(~Thunderbi@125.7.119.155) has joined #tryton09:11
-!- pokoli(~pokoli@unaffiliated/pokoli) has joined #tryton09:21
-!- michael-kohlhaas(~michael-k@unaffiliated/michael-kohlhaas) has joined #tryton09:45
-!- digitalsatori(~Thunderbi@125.7.119.155) has joined #tryton10:14
-!- nicoe(~nicoe@balisto.wifi.b2ck.com) has joined #tryton10:31
-!- Telesight(~anthony@4dafe0c0.ftth.telfortglasvezel.nl) has joined #tryton10:42
-!- Telesight(~anthony@4dafe0c0.ftth.telfortglasvezel.nl) has joined #tryton10:49
-!- VaticanCameos(~pritishc@182.68.223.3) has joined #tryton11:06
-!- Telesight(~anthony@4dafe0c0.ftth.telfortglasvezel.nl) has joined #tryton11:29
-!- Telesight(~anthony@4dafe0c0.ftth.telfortglasvezel.nl) has joined #tryton12:05
-!- mariomop(~quassel@host123.190-138-108.telecom.net.ar) has joined #tryton13:10
-!- Telesight(~anthony@4dafe0c0.ftth.telfortglasvezel.nl) has joined #tryton13:31
-!- cinik(~smilicic@cpe-188-252-142-163.zg5.cable.xnet.hr) has joined #tryton13:44
cinikHello!13:44
cinikI 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.13:46
cinikSorry - had some nickname issues13:51
cinikAnyway, I'm porting my old states="{'invisbile': Bool(Not(Equal(Eval('type_'),'N')))}" to something, and I get either of the following errors:13:52
cinikif I use proper JSON, {"invisble": "Eval(\"type_\") != \"N\" "}, then PYSON complains of getting a string.13:53
cinikif I skip the quotes, JSON complains about syntax errors13:53
cinikthis happens both with stock json and simplejson13:54
cinikplease help me :)13:54
-!- kstenger(~karla@200.124.209.158) has joined #tryton13:55
-!- rpit(~rpit@2a02:908:e670:6ac0:e037:d91f:e8bb:3f2e) has joined #tryton14:10
cedkcinik: the simpliest is to use http://doc.tryton.org/3.6/trytond/doc/ref/models/models.html?highlight=view_attribute#trytond.model.ModelView.view_attributes14:21
-!- juanfe(~juanfe@190.85.115.49) has joined #tryton14:43
-!- jcnorman(~jcnorman@24-197-138-90.dhcp.spbg.sc.charter.com) has joined #tryton15:04
-!- jcnorman_(~jcnorman@24-197-138-90.dhcp.spbg.sc.charter.com) has joined #tryton15:08
-!- bvillasanti(~bvillasan@181.16.21.34) has joined #tryton15:33
-!- nicoe(~nicoe@ptr-178-50-65-110.dyn.mobistar.be) has joined #tryton15:36
-!- smarro(~sebastian@181.192.57.21) has joined #tryton15:43
-!- nicoe(~nicoe@82-212-130-50.teledisnet.be) has joined #tryton16:03
cinikcedk: 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. :)16:10
cinikOne 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?16:13
cedkcinik: don't understand what is wrong with "PYSON string"16:13
cedkcinik: no16:14
cedkcinik: but patch is welcomed16:14
cinikcedk: 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...16:15
cedkcinik: you are not required to do so16:16
cedkcinik: you can put a PYSON string16:16
cinikI tried, but it wouldn't evaluate (my original question: either it fails as JSON or it fails as PYSON)16:18
cedkcinik: it works, you probably did not correctly encoded in the XML16:19
cedkcinik: that's why the ModelView.view_attributes is simplier because it does the job correctly16:19
cinikcedk: 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)16:21
cedkcinik: patch is welcome16:22
cinikcedk: I'll try to get around to it16:22
cinikcedk: 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).16:24
cinikcedk: what I wonder is how much that would be against some tryton metapriciple16:24
cedkcinik: don't understand16:25
cinikcedk: 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.16:28
cedkcinik: ModelSingleton should not be a special case16:35
cinikcedk: 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.16:47
cedkcinik: I don't see the logical for such call16:48
cinikcedk: 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?17:00
cinikcedk: sorry, should have been "the client calls model.default_get assuming the user wants to create a new record"17:01
-!- bvillasanti(~bvillasan@181.16.21.34) has joined #tryton17:08
cedkcinik: yes but it normal to call default_get when creating a record17:10
cinikcedk: 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 form17:15
cinikcedk: 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)17:16
cinik(sorry, that should have been "assumes the user wants to create a new record")17:16
cedkcinik: but a singleton doesn't necessary exist prior17:19
cinikcedk: 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 one17:21
cedkcinik: I don't agree because it leads to ackward behaviour17:23
cedkcinik: what if there is more than 1 record? Which one is shown?17:23
cinikcedk: 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 None17:24
cedkcinik: don't understand17:25
cinikcedk: 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 record17:25
cedkcinik: I don't understand what you mean by "default"17:25
cedkcinik: I don't see any generic behaviour in your examples17:25
cinikcedk: the behaviour of the client is if you open a form and there's no record selected, create a new one, right?17:27
cedkcinik: what do you mean by "record selected"?17:29
cinikcedk: 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 record17:31
cedkcinik: not necessary17:32
cedkcinik: it depends of the action17:32
cinikcedk: how?17:32
cedkcinik: look at the code17:33
-!- digitalsatori(~Thunderbi@203.35.234.18) has joined #tryton17:46
cinikcedk: 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_new17:48
cinikcedk: (thanks for making me find my way through the client code - I've been dreading that up until now :) )17:48
cedkcinik: I don't see the point to add an extra call while res_id is already doing the job17:50
cinikcedk: 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.17:52
cedkcinik: no it is create a double specs17:54
cinikcedk: sorry, I didn't understand that17:55
cedkcinik: there is already a parameter to do what you want: res_id17:55
cedkcinik: probably a solution will be to have a generic wizard that returns the right action (with res_id filled) to use on any singleton18:16
-!- kstenger(~karla@200.124.209.158) has joined #tryton18:34
-!- jcnorman(~jcnorman@24-197-138-90.dhcp.spbg.sc.charter.com) has joined #tryton19:03
-!- sunny_dealmeida(~quassel@203.115.83.43) has joined #tryton19:58
-!- cinik(~smilicic@cpe-188-252-142-163.zg5.cable.xnet.hr) has joined #tryton20:15
-!- rainer_s1nstwo(~rainer@pd956864b.dip0.t-ipconnect.de) has joined #tryton20:25
-!- FvD(~Thunderbi@ip95-153-64-186.ct.co.cr) has joined #tryton21:36
-!- FvD(~Thunderbi@ip95-153-64-186.ct.co.cr) has joined #tryton21:37
-!- smarro(~sebastian@181.192.57.21) has joined #tryton21:40
-!- pokoli(~pokoli@unaffiliated/pokoli) has joined #tryton21:51
-!- michael-kohlhaas(~michael-k@unaffiliated/michael-kohlhaas) has joined #tryton22:03
-!- FvD(~Thunderbi@ip95-153-64-186.ct.co.cr) has joined #tryton22:07
-!- FvD(~Thunderbi@ip95-153-64-186.ct.co.cr) has joined #tryton22:17
-!- pokoli(~pokoli@unaffiliated/pokoli) has joined #tryton22:21
-!- nineinchnick(~jwas@109.231.22.187) has joined #tryton22:24
-!- smarro(~sebastian@181.192.57.21) has joined #tryton22:29
-!- FvD(~Thunderbi@ip95-153-64-186.ct.co.cr) has joined #tryton22:30
-!- alimon(alimon@nat/intel/x-gnneymyqpexanntb) has joined #tryton23:28
-!- smarro(~sebastian@181.192.57.21) has joined #tryton23:47
-!- jcnorman(~jcnorman@24-197-138-90.dhcp.spbg.sc.charter.com) has joined #tryton23:52

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