IRC logs of #tryton for Sunday, 2011-10-23 #tryton log beginning Sun Oct 23 00:00:02 CEST 2011
cedkyangoon: I thought about the extension translation, I think it is better to leave it untranslated14:50
cedkmost are just the program name which is untranslatable14:50
cedkand also it is a technical part so only "Tech" guys see it so better to be sure that they understand it14:51
cedkalso we make reference in the help about unoconv extension compatibility which is in english14:51
-!- meanmicio(~lfm@fsf/member/meanmicio) has joined #tryton15:20
yangooncedk ok, again I have not so much concern about this, more important for me is translation of account charts15:39
yangooncedk: I hope translation on account charts will remian active?15:40
cedkyangoon: yes but we will need to improve it16:01
cedkyangoon: I'm loading all the translation to run clean on it and also pycountry16:01
yangooncedk: ok, so I don't push the last cleaned version16:02
cedkyangoon: ok if you did not change any translation16:03
bechamelyangoon: about trailing ":" on search string16:36
bechamelwhat do you think about usgin "back:" ?16:37
bechamelactually I was thinking that it was already necessary to put the "" to avoid parsing of :16:37
yangoon bechamel if you can put it, when there is no conflict with field name, would be good thing in my eyes16:39
bechamelyangoon: the main problem imo is that the user need to re-input the back: manually (for example to fix/complete it)16:41
yangoonif the search string will be changed from back: to "back:", the user can edit the search like always16:44
yangoonbechamel: probably I didn't understand your last sentence16:44
bechamelyangoon: my use case is: I put Name: in the search field and then I hit enter accidentally -> the string is lost16:46
bechameldiffrent but similar16:46
bechamelabout the second problem: it's possible to seach for a litteral %16:50
bechamelbut it's not user-friendly:16:50
bechamelSource: %\%%16:50
yangoon:), ok, thx16:51
yangoon1) we need a legend for available placeholders in search widget16:51
bechamelthis is passed as it to postgresql, and it's the way the % caracter must be escaped in sql16:51
yangoon2) we need saved searches, evtl. search history16:52
bechamel2) -> yes I think everobody agree on this16:52
bechamelwhat do you mean by "available placeholders" ?16:52
yangoon3) we need a simple completion, 'Tab' should complete in the search field instead of jumping to next (if possibel)16:52
yangoonbechamel: %, \ , finally all what is needed to make good use of search filed including operators16:53
bechamel3) -> tab is natural for CLI user, but I'm not sure lambda user would understand it16:53
bechamelIMO thinks like %\%% are ugly, we must find a better way to handle it16:55
bechamelbut I don't see how :)16:56
yangoonbbl shortly16:56
meanmicioHello there ! Do we have a module / functionality to assign a product to different categories ?17:55
cedkmeanmicio: not possible because of the way categories are used17:57
cedkmeanmicio: as default value for the product so having 2 categories is confusing17:57
meanmiciocedk : should we add another field that will be able to avoid replication ?17:59
cedkmeanmicio: don't know what is your usage of it18:00
meanmiciocedk : for example, aspirin can be in the antiinflammatory and in the anticoagulants18:02
udonomeanmicio: maybe you need something like tagging for products18:02
meanmiciocedk : two different categories18:02
cedkmeanmicio: what is the usage of "categories"?18:03
meanmiciocedk, uduno : I see it similar as to the party category, where it can belong to different categories18:05
udonomeanmicio: for me it sounds like 'tags'18:06
cedkmeanmicio: so there is no usage18:07
meanmiciouduno : Thanks. I check the tags concept. It's something that for the pharmacist or doctor to check in the product. The category concept is very nice.18:09
udonomeanmicio: the product category is for me more like "accounting category for products".18:09
udonomeanmicio: Tags have no good widgets in Tryton. But you can use a flat many2many list to say: Name: Aspirin; Tags: antiinflammatory, anticoagulants18:11
meanmiciouduno : In that case it makes more sense to be unique. Probably another field will complement the current functionality, and there will be no need to have two products with the same properties18:12
udonomeanmicio: I don't understand18:13
meanmiciouduno : Thanks. Today the "medicament" model inherits the product and I can put all the extra properties in this one, but the pharmacist can check directly on the product.18:14
meanmiciouduno : not big deal. It works fine today, but it can be optimized.18:14
yangoonmeanmicio: why not defining your own 'utilization category' as m2m?18:15
udono*utilization categories18:16
meanmiciouduno : It's good to have the concept of "accounting categories" in mind when refering to product category.18:16
cedkmeanmicio: I'm repeating myself but what is the usage?18:16
meanmiciouduno : That concept will be valid for many products, not only medicaments18:16
cedkyou can not design something correctly without knowing the usage of it18:17
meanmiciocedk : Let's think in general. Some product can be use in different contexts, so it will be desirable to have a field that group those contexts (same principle as the party categories)18:18
cedkmeanmicio: indeed I think it was a mistake to have the categories on party18:20
meanmiciocedk : I find it useful18:20
meanmiciocedk : I don't know whether is the right term, but the concept for grouping is important18:21
cedkmeanmicio: it is not important if there is no usage18:22
cedkit is against the KISS principle18:22
cedkmeanmicio: by the way, I think for medicaments it should have a standard classification18:23
meanmiciocedk : If you look at the latest GNU Health hg changeset you can find a nice example, when introducing the latest WHO essential medicines.18:24
cedkmeanmicio: last changeset is translation18:25
meanmiciocedk: Just do an update18:25
cedkmeanmicio: still the same18:26
meanmiciook, if you're in the latest revision, then you already have the new WHO update. Check on the product categories18:27
cedkmeanmicio: where is the code?18:28
meanmiciocheck WHO_list_of_essential_medicines.xml and medicament_categories.xml18:30
cedkmeanmicio: looking at the amount of product.category you get, I really think it is not the right place18:30
cedkmeanmicio: i think you should have to create a field who's category18:34
meanmiciocedk : In that case, I rather create it not in the product, but in the medicament model18:35
meanmiciocedk : that inherit and enhances the product model18:36
cedkmeanmicio: yes of course18:37
meanmiciocedk : with all the properties (mechanism of action, storage, adverse reaction,... )18:37
meanmiciocedk : ok.18:37
cedkmeanmicio: also it will prevent to classify a product which is not a medicament in the WHO's list18:37
meanmiciocedk : So, in products, should we fill all the products in one single category ?18:39
meanmiciocedk : I mean all the medicaments in one single product category ?18:40
cedkmeanmicio: don't know, if all the medicaments share the same default values (accounts, taxes etc.) so yes18:41
udonomeanmicio: you said: "... but the pharmacist can check directly on the product." Did the pharmacist need the who's category information, too?18:45
meanmiciocedk : Yes. That would be the case.18:45
meanmiciocedk : Or it would depend on particular cases ( generic vs brand name)18:46
meanmiciouduno : Yes, for example, some countries today has as law the generic (active component) name of the medicine. So, the doctor prescribes the active component, and the pharmacist looks for the active component (generic), having a list of all the medicaments matching that. That's how the WHO works also18:48
meanmiciouduno : So what I will do is create the category tree in the medicament model, and not in the product. We have to keep in mind that different health centers work in different ways, so some of them will use WHO, but some others might not18:51
udonomeanmicio: for me it sounds strange: ... but the pharmacist can check directly on the product... the pharmacist need the who's category information ... create the category tree in the medicament model, and not in the product.18:52
meanmiciouduno : That is what Cedric is also suggesting. So, it looks that we have consensus :-)18:55
meanmiciouduno : I will leave empty the product field, so they can fill it with whatever specific brand they have.18:56
meanmiciouduno : Looks it will be more efficient this way.18:59
cedkmeanmicio: yes I guess somes will use one product for every medicaments19:00
meanmiciocedk : Exactly. So in the case of aspirin, they will use the same product (acetylsalicylic acid) with different doses for antiinflammatory or antigregant19:03
meanmiciocedk : but we avoid having that same active component to be twice in the product list19:03
meanmiciocedk : Sometimes, they come in different presentations (eg, capsule of 500mg or 1g ), so in that case, there will be two products19:05
meanmiciocedk : but that won't affect the medication.19:05
meanmiciocedk : so now is just a matter of adding a category field to the medication and replace the model in the xml files. Time to work :-)19:07
udonomeanmicio: As far as I understand, you have a generic acetylsalicylic acid (product.template) and brand names like Aspirin, ACC(product.product, which refers to the same template). These products have  medical, pharmaceutical, therapeutical aspects.19:09
meanmiciouduno : Yes. But now we will pass that WHO categorization to the medicament model19:11
udonomeanmicio: You have to do what you have to do ;-)19:12
meanmiciouduno : So, there it makes sense to have it twice (so aspirin will be in the NSAID and anticoagulant categories), but they will refer to a single product.19:13
meanmiciouduno : :-) This type of things are much clearer using verbal communication :-)19:14
udonomeanmicio: Without an idea about the use and the need of all kind of products used in your case: I don't know.19:17
meanmiciouduno : right. It's quite specific, but having the medicament model today, this change will optimize the whole process... I will update you in a while, and you can check the new functionality19:20
meanmiciouduno / cedric : Thanks for your suggestions !19:21
udonomeanmicio: that's good.19:21
meanmiciocedk : ping22:14
meanmiciocedk : memory consumption has been greatly reduced in this new Tryton version ! Now it loads the whole 80000 Medical Procedures with a very small memory footprint. Congratulations !22:16
-!- ciupicri(~ciupicri@unaffiliated/ciupicri) has joined #tryton22:18
cedkmeanmicio: pong22:21
cedkmeanmicio: thx22:21
cedkmeanmicio: perhaps I will be able to install all the GNUHealth modules on my EeePC :-)22:22
meanmiciocedk : You should :-) It only took about 90 MB. Major improvement !22:27
cedkmeanmicio: I will22:37
cedkmeanmicio: now there is no fear to do: self.browse([]))22:37
meanmiciocedk : no fear either to look check for swap22:40
meanmiciocedk : 1.4.0 should go to Pypi22:40
meanmiciocedk : People will find it easier to install now22:41
cedkmeanmicio: normally: $ make release22:57
cedkmeanmicio: should do the work but I did not test abvously :-)22:57
meanmiciocedk : I will wait until Tryton 2.2 is out. Then I will make the standard package, check it and when everything is ok (let's cross our fingers), I will do the make release23:00
cedkmeanmicio: make release does the packaging also and upload it to pypi23:14
meanmiciocedk : great. I think I will ask you to check it once I have it ready :-)23:16

Generated by 2.11.0 by Marius Gedminas - find it at!