IRC logs of #tryton for Saturday, 2010-11-27 #tryton log beginning Sat Nov 27 00:00:02 CET 2010
-!- johbo_( has joined #tryton00:01
-!- johbo__( has joined #tryton00:01
-!- 20QACOSLS( has joined #tryton01:16
-!- 94SAAEJSG( has joined #tryton01:16
-!- johbo( has joined #tryton03:03
-!- johbo_( has joined #tryton03:03
-!- jcm( has joined #tryton03:17
-!- sharoon(~sharoon@ has joined #tryton04:16
-!- sharoon(~sharoon@ has joined #tryton05:06
-!- yangoon( has joined #tryton05:17
-!- gremly(~gremly@ has joined #tryton05:37
-!- woakas(~woakas@ has joined #tryton05:37
-!- johbo__( has joined #tryton06:51
-!- johbo( has joined #tryton06:51
-!- jcm( has joined #tryton08:17
-!- chrue( has joined #tryton08:53
-!- JoePass(~gasbakid@ has joined #tryton09:09
-!- trifon( has joined #tryton09:11
-!- Timitos(~kp@ has joined #tryton09:45
-!- vladimir_(~vladimir@ has joined #tryton10:01
-!- GasbaKid(~GasbaKid@ has joined #tryton10:10
-!- chrue( has joined #tryton10:15
-!- JoePass(~gasbakid@ has joined #tryton10:38
-!- heffer(~felix@fedora/heffer) has joined #tryton10:58
sharoonDoes Model.raise_user_warning rollback the cursor?11:33
cedksharoon: yes11:50
sharooncedk: so if i want to save the changes but still raise an error I have to manually do a Transaction().cursor.commit11:50
cedksharoon: yes but it is a bad idea11:50
sharooncedk: any other alternative you could suggest11:51
cedksharoon: I don't see any logical in having an error but doing stuff anyway11:52
cedksharoon: I don't see the point11:54
sharooncedk: in the three levels of credit limit check, the first two levels allow document to be saved, but throws a warning11:55
sharooncedk: while the last stage prevents the document from being saved (can be handled by the raise_user_error)11:55
cedksharoon: why not using warning like they were design?11:58
cedksharoon: so the user will choose to bypass or not the warning11:59
cedkpopups without decision are useless and will be ignored by the user with time11:59
sharooncedk: as you can see in the link i sent, credit limit check can be enforced with any document/transaction/record12:00
sharooncedk: this could be implemented by ir.triggers easily for any model without writing boilerplate code for each model12:00
sharooncedk: code needs to be specific only for the stock module (to prevent delivery in case 2)12:00
sharooncedk: can you suggest an idea, how the decision making boxes could be shown to the user in a generic design (not specific to invoice/sale order?)12:01
cedksharoon: I don't understand the design of SAP12:06
sharooncedk: :D12:07
cedksharoon: I don't understand why you speak about any document12:08
cedksharoon: every document is not linked to accounting12:08
sharooncedk: example a support ticket12:08
cedkI think it is not a good target to try to make something generic here12:09
sharooncedk: we dont want support tickets to be answered if customer is in credit exceeded state?12:09
cedkbecause there is so many ways and policies that could exist12:09
cedksharoon: I don't know it depends of the policies of the company12:09
sharooncedk: that is a different module :
sharooncedk: while what i just showed you is simple credit limit check - its NOT 'credit management'12:13
cedksharoon: and what?12:21
sharooncedk: so what do you think will be the best way to implement this simple_credit_limit_check ;)12:21
cedksharoon: I will create a module that define credit check for a party12:23
sharooncedk: you could suggest the blueprint like email and we could implement too?12:24
cedksharoon: create a method that takes a party and raise or not a warning12:24
sharooncedk: ok12:24
cedksharoon: that can be forced or not12:24
cedksharoon: then you can have many others modules that depends on this one that will add check in specific placies of tryton12:25
cedklike on sale validation or packing or invoice etc...12:25
sharooncedk: what i thought for simple limit check was - have three numeric fields inside party to have a 'warning_limit', 'delivery_block_limit' and a 'stop_limit'12:25
cedksharoon: for a blueprint, I don't know enough on common practice on what could be based credit check to write one12:26
cedksharoon: I think it is too specific12:27
cedksharoon: i think just one limit for warning and an other one for block12:27
cedksharoon: and other modules could extend the check method to use other fields (like limit for delivery)12:28
sharooncedk: ok12:28
sharooncedk: i will push the simple module with the two fields for review and then proceed with the design12:29
yangoonperhaps a checkbox 'blocked' on party could fit into this module, too12:30
yangoonif you want to block nay service to this party independent from limits12:30
cedksharoon: in fact limit should be by default on company12:32
cedkyangoon: the check box is simply put the limit to 012:33
sharooncedk: no the limit is defined by the user, it could be 'available_credit' which could set to 012:33
yangooncedk: so you have limit on company and on party?12:33
sharooncedk: yangoon: limit on company will function like 'credit area' in sap12:34
cedkyangoon: yes, a default one on company that apply to every parties and one on party to overload the company default12:36
yangooncedk: +112:36
udonosharoon: cedk: When will the user warning be raised?12:36
sharooncedk: company policy will be singleton?12:36
udonosharoon: property?12:36
cedksharoon: why not, not yet sure12:36
cedkudono: of course it should be a property on party12:37
sharooncedk: udono: yep :)12:37
cedkACTION bbl12:37
udonosharoon: cedk: When will the user warning be raised?12:38
-!- chrue( has joined #tryton12:38
sharoonudono: IMHO, it should be trigger based?12:38
sharoonudono: which would mean it is completely 'configurable'12:39
udonosharoon: ok, but when it is raised, e.g. on choosing a party, on success a workflow step,...?12:40
udono... choosing a party won't work12:41
sharoonudono: it would be Create/Write etc as with ir.trigger and satisfying the condition of trigger12:41
sharoonudono: eg: Model: sale.order | write event | condition: state='confir,'12:42
udonoACTION has to take a deeper look into the ir.trigger conception12:44
udonosharoon: sounds good!, thanks12:44
sharoonudono: :) i have used trigger in email_template also12:44
udonosharoon: yes, I have seen it.12:44
-!- pjstevns( has joined #tryton12:52
-!- lem0na(~lem0na@ has joined #tryton13:12
-!- JoePass(~gasbakid@ has joined #tryton13:17
-!- lem0na(~lem0na@ has joined #tryton13:18
-!- pjstevns( has left #tryton13:47
cedksharoon: I don't see how you could use trigger for that14:10
cedksharoon: you don't know where will be the party to check for a Model14:10
sharooncedk: i see the problem now too14:10
cedksharoon: and also, I think most of the check will be on workflow activity14:11
cedkinstead on each create/write14:11
sharooncedk: ok14:11
sharooncedk: which means we extend workflow.activity14:12
cedkfor sale, you will want to have sale order in draft even if there is credit issue with the customer14:12
cedkbut you don't want to go further14:12
sharooncedk: you are right14:12
cedksharoon: you can not extend workflow activity because once again you don't know where is the party to check14:13
cedkthis is a developper job to place the check at the right place14:13
sharooncedk: assuming our standard we could guess it as field 'party' ? but that would be cowboy coding14:13
cedksharoon: yes14:13
sharooncedk: so do you get any ideas?14:14
cedksharoon: I think that we put the framework to implement a credit policy but let to the implementor to define in with a module that will put at the right places the call to the credit check14:17
sharooncedk: i agree with you - maybe something as simple as :14:18
cedksharoon: yes with perhaps the record from where you are calling14:19
sharooncedk: ok14:20
sharooncedk: and any idea about how we implement just a warning (but still commit)14:20
cedksharoon: no14:22
sharooncedk: do you think its an useful feature that could be part of the framework?14:23
cedksharoon: as I already said, this is not a good flow to do stuff and after warn the user14:23
sharooncedk: ok14:24
sharooncedk: but we need atleast a way to display information to the user14:24
sharoona server side generated message14:24
yangooncedk: to have some kind of popup would be generally very useful14:24
cedkit is warning14:25
-!- JoePass(~gasbakid@ has joined #tryton14:33
-!- paepke( has joined #tryton14:40
-!- johbo( has joined #tryton14:49
-!- chrue( has joined #tryton14:50
paepkesharoon, cedk, yangoon what the use of the colored bar in the top right of a form. Its currently there with a green message when you save for example a dataset. Can this be triggered somehow?15:06
paepkeok, its not that much text in there..15:06
sharoonpaepke: but if could have some way to trigger a message there, i guess it solves a lot of the problem15:07
sharooncedk: what do you think of the feasibility of the feature?15:08
cedkI don't understand what you want to display15:32
-!- heg( has left #tryton15:44
-!- ikks(~ikks@ has joined #tryton16:36
-!- lem0na(~lem0na@ has joined #tryton16:37
-!- enlightx( has joined #tryton17:29
yangooncedk: ping17:54
yangooncedk: for there is a lot of currency_obj.compute17:55
yangoonwould you prefer to put date in ctx or to change objjects to .ids17:55
-!- lem0na(~lem0na@ has joined #tryton18:01
cedkyangoon: i don't know18:03
yangoonprobably better to put in ctx, because then it can be accounting_date or invoice_date or today18:04
cedkyangoon: pass ids but I don't know what is the right date to use in context18:06
-!- johbo_( has joined #tryton18:42
-!- JoePass(~gasbakid@ has joined #tryton18:46
-!- johbo( has joined #tryton19:09
-!- Timitos1(~kp@ has joined #tryton19:39
-!- sharkcz(~sharkcz@2001:15c0:6747:160::7) has joined #tryton19:39
-!- masterhumper(~SeJo@exherbo/developer/sejo) has joined #tryton19:39
-!- heffer(~felix@fedora/heffer) has joined #tryton19:40
-!- GasbaKid(~GasbaKid@ has joined #tryton19:40
-!- johbo_( has joined #tryton19:51
-!- vladimir_(~vladimir@ has joined #tryton20:07
-!- droid2(~droid@ has joined #tryton20:07
droid2Hi , anybody there ?20:09
-!- irclog( has joined #tryton20:37
-!- johbo( has joined #tryton20:49
-!- gremly(~gremly@ has joined #tryton21:00
-!- gavinf( has joined #tryton21:17
-!- zodman(~zodman@foresight/developer/zodman) has joined #tryton21:28
-!- sharkcz(~sharkcz@2001:15c0:6747:160::7) has joined #tryton21:48
-!- cedk(ced@gentoo/developer/cedk) has joined #tryton22:06
lem0nacedk: now in form of patches22:07
cedklem0na: can you send me an email22:09
lem0nacedk: sure22:09
-!- cedk(ced@gentoo/developer/cedk) has joined #tryton22:10
lem0nacedk: info_at_b2ck_dot_com?22:11
cedklem0na: cedric.krier at ...22:12
-!- bechamel( has joined #tryton22:13
lem0nacedk: done22:13
cedklem0na: I will check tomorow22:17
-!- cedk(ced@gentoo/developer/cedk) has joined #tryton22:19
-!- cedk(ced@gentoo/developer/cedk) has joined #tryton22:40
-!- zodman(~zodman@foresight/developer/zodman) has joined #tryton23:31

Generated by 2.11.0 by Marius Gedminas - find it at!