IRC logs of #tryton for Wednesday, 2015-02-11

chat.freenode.net #tryton log beginning Wed Feb 11 00:00:01 CET 2015
-!- matiassm(~smuxi@181.167.21.243) has joined #tryton03:06
-!- matiassm(~smuxi@181.167.21.243) has joined #tryton03:08
-!- digitalsatori(~Thunderbi@116.234.198.143) has joined #tryton03:36
-!- uranus(~uranus@ip72-192-133-197.sd.sd.cox.net) has joined #tryton04:58
-!- yangoon(~mathiasb@p549F1591.dip0.t-ipconnect.de) has joined #tryton06:02
-!- TheCowboy`(~TheCowboy@ip68-98-183-236.dc.dc.cox.net) has joined #tryton06:09
-!- frispete_(~frispete@p54A902EA.dip0.t-ipconnect.de) has joined #tryton06:40
-!- digitalsatori(~Thunderbi@116.234.198.143) has joined #tryton07:02
-!- uranus(~uranus@ip72-192-133-197.sd.sd.cox.net) has joined #tryton07:02
-!- VaticanCameos(~pritishc@103.245.118.154) has joined #tryton07:04
VaticanCameosIs there a way to persistently display a particular type of a warning (for eg, those warnings whose names end in a suffix) even if the user clicks Yes? I tried doing so by deleting the active record of the warning but this only leads to an infinite loop of warning dialog boxes.07:06
VaticanCameosThe warning should be persistent in all other situations except for when the user clicks the always box to ignore it.07:07
apostatizeOh, you mean, like those situations where the warning is, for example, "Are you sure?" Then has a checkbox "Do not display again?"?07:22
apostatizeVaticanCameos: Or something else?07:22
VaticanCameosapostatize: I think Tryton user warnings always have that 'do not display again' checkbox.07:24
apostatizeVaticanCameos: Hmmm... there are error messages that don't, I don't think. For example, in Health, there is a warning that must be acknowledged to go away (for drug prescription for pregnant patients). I think, at least.07:29
VaticanCameosapostatize: By persistent I meant that the warning should appear everytime the condition that triggers it occurs, even if the user has clicked Yes. The only way to put away the warning would be to tick the ignore always/don't show again box.07:31
apostatizeVaticanCameos: Ok, I'm understanding it better. Let me see.07:33
apostatizeVaticanCameos: I'm looking at the code for the Health warning, and what it does is call a function to check if the user has verified the prescription (it saves True/False in the model). Hmm...07:36
apostatizeVaticanCameos: Save the warning state, then check it each time?07:38
VaticanCameosapostatize: In my case, I'm thinking of making this warning different from regular warnings by making the warning_name end in a suffix (say, 'reraise'). For unique warning names, I would do '%s.reraise' % model_active_record. Not sure saving True/False in the model would help in this case..07:38
apostatizeVaticanCameos: Yeah, hmm...07:39
VaticanCameosapostatize: thanks for helping out all the same though07:39
apostatizeVaticanCameos: Hehe, interesting problem. =-) I'm still thinking, not the most familiar with the intricacies. cedk would be a great help. Hmm...07:40
apostatizeVaticanCameos: Pseudo-code/thougths: I don't know how to read the warning state, but it says it does save it. Check it, and if not ignore all, raise it again.07:50
apostatizeVaticanCameos: So, res.user.warning holds the warning state, I believe. You can query it yourself, and check how the warning was handled.07:57
apostatizeVaticanCameos: So, how I'm reading the code is that unless the attribute *always* is true, the warning is deleted.08:06
-!- marius_(~marius@v100.nfq.lt) has joined #tryton08:07
VaticanCameosapostatize: Indeed that is so. I'm raising the warning in an unusual situation though (in an on_change method), and this calls for measures not usually required (committing the Transaction cursor from inside of which I'm raising the warning).08:07
VaticanCameosThe committing allows the delete() to persist.08:08
VaticanCameosSo now it works.08:08
apostatizeOh, it's working how you want? Or? =-)08:09
apostatizeVaticanCameos: Yeah, the Health warning I'm looking at, what it cleverly does is reset the saved True/False values, so the warning is displayed again.08:12
VaticanCameosapostatize: yep, it's working persistently now.08:13
apostatizeVaticanCameos: Great! I got to do some unhelpful code diving, and you fixed it! Lol. =-)08:13
VaticanCameosapostatize: My fault really. I should've explained the context better.08:14
apostatizeVaticanCameos: Haha, no worries, not too familiar with the intricacies anyways. Fixed is fixed. =-)08:15
VaticanCameosWarnings are not to be raised in on_change methods because they run in roll-backed transactions.08:15
VaticanCameosThe situation was not of the usual kind.08:15
VaticanCameosapostatize: thanks for the help!08:15
apostatizeVaticanCameos: Hehe, you're welcome, for the little I did. =-)08:17
apostatizeGotta afk. Take care.08:17
-!- pobsteta(~Thunderbi@196.201.26.109.rev.sfr.net) has joined #tryton08:58
-!- cedk(~ced@gentoo/developer/cedk) has joined #tryton09:19
-!- Telesight(~anthony@4daedff9.ftth.telfortglasvezel.nl) has joined #tryton10:15
-!- jcros(~Thunderbi@187.176.125.78.rev.sfr.net) has joined #tryton10:30
-!- digitalsatori(~Thunderbi@116.234.198.143) has joined #tryton11:00
-!- hiaselhans(~Thunderbi@chello212186043057.408.14.vie.surfer.at) has joined #tryton11:09
-!- nicoe(~nicoe@balisto.wifi.b2ck.com) has joined #tryton11:23
-!- kstenger(~karla@200.124.209.158) has joined #tryton11:46
-!- mariomop(~quassel@host252.190-137-65.telecom.net.ar) has joined #tryton11:53
-!- VaticanCameos(~pritishc@103.245.118.154) has joined #tryton12:26
marius_is there some javascript library for calling jsonrpc calls of tryton?13:11
marius_like proteus probably, but in javascript :D13:11
cedkmarius_: you can grab the sao one13:14
-!- woakas(~woakas@static.13.240.46.78.clients.your-server.de) has joined #tryton14:17
-!- bvillasanti(~bvillasan@181.16.28.146) has joined #tryton14:28
-!- hiaselhans(~Thunderbi@chello212186043057.408.14.vie.surfer.at) has joined #tryton15:32
-!- hiaselha1(~Thunderbi@chello212186043057.408.14.vie.surfer.at) has joined #tryton15:33
-!- Telesight(~anthony@4daedff9.ftth.telfortglasvezel.nl) has joined #tryton15:53
-!- notzippy(~sabayonus@d207-216-251-90.bchsia.telus.net) has joined #tryton16:46
-!- jcros(~Thunderbi@187.176.125.78.rev.sfr.net) has joined #tryton17:14
-!- udono(~udono@p50938317.dip0.t-ipconnect.de) has joined #tryton17:19
-!- mariomop(~quassel@host252.190-137-65.telecom.net.ar) has joined #tryton17:41
-!- lukio(~lukio@110-189-235-201.fibertel.com.ar) has joined #tryton17:50
-!- newzen(~newzen@190.36.80.12) has joined #tryton18:49
-!- bvillasanti(~bvillasan@181.16.28.146) has joined #tryton18:55
-!- TheCowboy`(~TheCowboy@wsip-98-191-208-98.dc.dc.cox.net) has joined #tryton19:11
-!- TheCowboy`(~TheCowboy@wsip-98-191-208-111.dc.dc.cox.net) has joined #tryton19:31
-!- frispete(~frispete@p54A902EA.dip0.t-ipconnect.de) has joined #tryton19:36
-!- vcardon(~vcardon@bureau-sdsl.tranquil.it) has left #tryton19:36
-!- pablovannini(~pablo@110-189-235-201.fibertel.com.ar) has joined #tryton19:40
-!- Rollo(~Thunderbi@ipservice-092-208-139-252.092.208.pools.vodafone-ip.de) has joined #tryton19:55
Rollohi again19:55
Rollohow account_invoice is keeping the historical address?19:57
Rollook - found it20:10
-!- hiaselhans(~Thunderbi@80.122.89.139) has joined #tryton20:12
-!- Rollo(~Thunderbi@ipservice-092-208-139-252.092.208.pools.vodafone-ip.de) has joined #tryton21:32
-!- funnybunny(funnybunny@gateway/shell/blinkenshell.org/x-pkurkzgutdeizkpf) has joined #tryton21:41
-!- funnybunny(funnybunny@unaffiliated/funnybunny) has joined #tryton21:41
-!- funnybunny(funnybunny@gateway/shell/blinkenshell.org/x-pkurkzgutdeizkpf) has joined #tryton21:41
-!- pobsteta(~Thunderbi@4cb54-3-88-160-87-54.fbx.proxad.net) has joined #tryton21:48
-!- hiaselhans(~Thunderbi@chello212186043057.408.14.vie.surfer.at) has joined #tryton22:27
-!- marius_(~marius@84.240.8.12) has joined #tryton22:40
-!- bvillasanti(~bvillasan@181.16.28.146) has joined #tryton22:42
-!- nineinchnick1(~jwas@185.13.233.190) has joined #tryton23:36

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