IRC logs of #tryton for Tuesday, 2015-07-14 #tryton log beginning Tue Jul 14 00:00:03 CEST 2015
2015-07-14 00:29 -!- smarro(~sebastian@ has joined #tryton
2015-07-14 00:58 -!- jcnorman( has joined #tryton
2015-07-14 01:14 -!- jcnorman( has joined #tryton
2015-07-14 01:30 -!- jcnorman( has joined #tryton
2015-07-14 01:37 -!- smarro(~sebastian@ has joined #tryton
2015-07-14 02:16 -!- pablovannini(~pablo@ has joined #tryton
2015-07-14 06:40 -!- frispete( has joined #tryton
2015-07-14 06:43 -!- udono( has joined #tryton
2015-07-14 06:55 -!- VaticanCameos(~pritishc@ has joined #tryton
2015-07-14 06:59 -!- LordVan(~LordVan@gentoo/developer/LordVan) has joined #tryton
2015-07-14 07:01 -!- yangoon( has joined #tryton
2015-07-14 07:58 -!- Telesight( has joined #tryton
2015-07-14 08:17 -!- digitalsatori(~Thunderbi@ has joined #tryton
2015-07-14 08:30 -!- digitalsatori(~Thunderbi@ has joined #tryton
2015-07-14 08:38 -!- digitalsatori(~Thunderbi@ 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@ has joined #tryton
2015-07-14 09:09 -!- digitalsatori(~Thunderbi@ has joined #tryton
2015-07-14 09:11 -!- digitalsatori(~Thunderbi@ 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@ has joined #tryton
2015-07-14 10:31 -!- nicoe( has joined #tryton
2015-07-14 10:42 -!- Telesight( has joined #tryton
2015-07-14 10:49 -!- Telesight( has joined #tryton
2015-07-14 11:06 -!- VaticanCameos(~pritishc@ has joined #tryton
2015-07-14 11:29 -!- Telesight( has joined #tryton
2015-07-14 12:05 -!- Telesight( has joined #tryton
2015-07-14 13:10 -!- mariomop( has joined #tryton
2015-07-14 13:31 -!- Telesight( has joined #tryton
2015-07-14 13:44 -!- cinik( 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@ 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
2015-07-14 14:43 -!- juanfe(~juanfe@ has joined #tryton
2015-07-14 15:04 -!- jcnorman( has joined #tryton
2015-07-14 15:08 -!- jcnorman_( has joined #tryton
2015-07-14 15:33 -!- bvillasanti(~bvillasan@ has joined #tryton
2015-07-14 15:36 -!- nicoe( has joined #tryton
2015-07-14 15:43 -!- smarro(~sebastian@ has joined #tryton
2015-07-14 16:03 -!- nicoe( 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@ 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@ 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@ has joined #tryton
2015-07-14 19:03 -!- jcnorman( has joined #tryton
2015-07-14 19:58 -!- sunny_dealmeida(~quassel@ has joined #tryton
2015-07-14 20:15 -!- cinik( has joined #tryton
2015-07-14 20:25 -!- rainer_s1nstwo( has joined #tryton
2015-07-14 21:36 -!- FvD( has joined #tryton
2015-07-14 21:37 -!- FvD( has joined #tryton
2015-07-14 21:40 -!- smarro(~sebastian@ 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( has joined #tryton
2015-07-14 22:17 -!- FvD( has joined #tryton
2015-07-14 22:21 -!- pokoli(~pokoli@unaffiliated/pokoli) has joined #tryton
2015-07-14 22:24 -!- nineinchnick(~jwas@ has joined #tryton
2015-07-14 22:29 -!- smarro(~sebastian@ has joined #tryton
2015-07-14 22:30 -!- FvD( has joined #tryton
2015-07-14 23:28 -!- alimon(alimon@nat/intel/x-gnneymyqpexanntb) has joined #tryton
2015-07-14 23:47 -!- smarro(~sebastian@ has joined #tryton
2015-07-14 23:52 -!- jcnorman( has joined #tryton

Generated by 2.17.3 by Marius Gedminas - find it at!