| chat.freenode.net #tryton log beginning Fri Nov 4 00:00:02 CET 2011 | ||
| 2011-11-04 05:46 <zxq9> Is there a way to save a picture as binary data in the database, and then display it in a view? | ||
| 2011-11-04 10:07 <enlightx> hi *, does tryton have this problem too? https://bugs.launchpad.net/openobject-addons/+bug/707923 | ||
| 2011-11-04 10:07 <enlightx> vat computation "by row" or "by column" is the topic | ||
| 2011-11-04 10:14 <cedk> enlightx: http://hg.tryton.org/modules/account_invoice/file/713048f28dc6/invoice.py#l406 | ||
| 2011-11-04 10:14 <cedk> enlightx: http://hg.tryton.org/modules/sale/file/309ef16bf19b/sale.py#l457 | ||
| 2011-11-04 10:14 <cedk> enlightx: rounding is done per tax key | ||
| 2011-11-04 10:15 <enlightx> cedk: actually it's not a real rounding problems, that depends on the way you sum the vat. you can compute the vat of each line then sum it, or you can compute the vat on the total amount (everything grouped by tax rate of course) | ||
| 2011-11-04 10:16 <enlightx> openerp does it the first way | ||
| 2011-11-04 10:16 <enlightx> which is not ok in italy and switzerland and germany afaik | ||
| 2011-11-04 10:18 <cedk> enlightx: I think both method are valid in all countries but it is not the natural way | ||
| 2011-11-04 10:18 <cedk> enlightx: especially when there is only 1 taxes | ||
| 2011-11-04 10:18 <cedk> see the screenshot https://bugs.launchpad.net/openobject-addons/+bug/707923/+attachment/1807906/+files/tax_rounding.png | ||
| 2011-11-04 10:18 <enlightx> cedk: yes, the problem happens when you have more than one tax | ||
| 2011-11-04 10:19 <enlightx> and we are always talking about 1 cents of difference | ||
| 2011-11-04 10:20 <enlightx> cedk: anyway, in italy and switzerland we usually compute vat by column, in fact with openerp we often cannot record supplier invoices for this reason | ||
| 2011-11-04 10:20 <enlightx> and WE CANNOT trick the invoice as Fabien suggested (rant) | ||
| 2011-11-04 10:21 <enlightx> so, i'm starting to be quite upset and searching for an openerp alternative :-) | ||
| 2011-11-04 10:21 <zxq9> <-- Would be upset if his country had VAT in the first place... | ||
| 2011-11-04 10:22 <cedk> enlightx: rounding as we do is a little bit more complicate but it works better for every one | ||
| 2011-11-04 10:22 <enlightx> zxq9: both ways must be supported | ||
| 2011-11-04 10:22 <cedk> zxq9: in Japan there is no VAT? | ||
| 2011-11-04 10:22 <enlightx> cedk: that could be enough indeed | ||
| 2011-11-04 10:24 <zxq9> No VAT the way you guys have it in Europe -- and no taxes which cross national boundaries, that is tricky/dangerous. | ||
| 2011-11-04 10:26 <enlightx> zxq9: you lucky :) | ||
| 2011-11-04 10:26 <zxq9> Actually, for that reason I've had to remove a lot of VAT related code to use Tryton in Japan and USA -- there are very many European specific assumptions. | ||
| 2011-11-04 10:26 <cedk> zxq9: I don't understand? What did you remove? | ||
| 2011-11-04 10:27 <zxq9> Anything called "VAT" for one thing. | ||
| 2011-11-04 10:27 <zxq9> And there is a lot, in accounting and invoice code. | ||
| 2011-11-04 10:27 <nicoe> you meant the vocabulary | ||
| 2011-11-04 10:27 <zxq9> But not all countries have VAT, and VIES only makes sense in Europe. | ||
| 2011-11-04 10:27 <nicoe> not the code | ||
| 2011-11-04 10:27 <zxq9> Not just vocabulary. | ||
| 2011-11-04 10:28 <zxq9> Supplier-supplier transactions are not taxed in many countries. | ||
| 2011-11-04 10:28 <cedk> zxq9: it is just one field in Party form | ||
| 2011-11-04 10:28 <zxq9> Retail is taxed in such countries. | ||
| 2011-11-04 10:28 <nicoe> I don't understand what you had to remove | ||
| 2011-11-04 10:28 <cedk> zxq9: there is no VAT reference in the account module | ||
| 2011-11-04 10:28 <nicoe> Do you have a patch ? | ||
| 2011-11-04 10:30 <zxq9> nicoe: Just branched modules, not patches. | ||
| 2011-11-04 10:31 <cedk> zxq9: that's a bad idea for the future | ||
| 2011-11-04 10:31 <zxq9> Maybe. But the structure for things like the party module don't fit what we're using the engine for. | ||
| 2011-11-04 10:31 <zxq9> But the engine is extremely useful to build on. | ||
| 2011-11-04 10:34 <cedk> zxq9: it is very strange because party module is very generic | ||
| 2011-11-04 10:34 <zxq9> Which reminds me... is there a straightforward way to suppress the output of commas on large integer fields in a form? | ||
| 2011-11-04 10:35 <cedk> zxq9: in language definition | ||
| 2011-11-04 10:35 <zxq9> cedk: it makes assumptions about certain things related to how organizations are formed, and doesn't permit many2many location/address relationships, etc. | ||
| 2011-11-04 10:35 <cedk> zxq9: what ? | ||
| 2011-11-04 10:36 <cedk> zxq9: you mean that a company could have only one address? | ||
| 2011-11-04 10:36 <zxq9> Is it possible to suppress commas in integer output in one specific form field? Or should I cast it to a string before displaying? | ||
| 2011-11-04 10:36 <zxq9> cedk: No, that many people may share the same address. | ||
| 2011-11-04 10:36 <cedk> zxq9: it is global | ||
| 2011-11-04 10:36 <cedk> zxq9: ok but you can not share it | ||
| 2011-11-04 10:36 <zxq9> cedk: Also, addressing in Asia is by zone, sub-zone, etc. There are no street names or anything, as well as the typical CJK language issues. | ||
| 2011-11-04 10:39 <cedk> zxq9: have you a schema of such addresses? | ||
| 2011-11-04 10:40 <zxq9> I have made one. It is a bit complex because it must accept three optional spellings for each field. When using PostgreSQL directly this would be usually done by making each field an array, but in Tryton we've just made 3 fields for each (for now anyway). | ||
| 2011-11-04 10:42 <udono> zxq9: do you mean the thousand-seperator on integer fields? | ||
| 2011-11-04 10:42 <zxq9> udono: yes | ||
| 2011-11-04 10:45 <zxq9> Is there a way to store an image as binary data, and then display it within a form? | ||
| 2011-11-04 10:45 <zxq9> or does it need to be saved in share/pixmaps first and then referenced by name? | ||
| 2011-11-04 10:48 <cedk> https://secure.wikimedia.org/wikipedia/en/wiki/Japanese_addressing_system | ||
| 2011-11-04 10:48 <cedk> zxq9: I looks like it can match | ||
| 2011-11-04 10:49 <nicoe> zxq9: you can display images in the client. gnuhealth do so. | ||
| 2011-11-04 10:49 <nicoe> Use a binary field and a widget image | ||
| 2011-11-04 10:49 <nicoe> <field name="my_picture" widget="image" /> | ||
| 2011-11-04 10:50 <zxq9> cedk: Match what? The current schema? Because it doesn't. The order problem is resolved with simply making a new form view, but the bigger problem is handling spellings in international business environment (even domestic, actually) | ||
| 2011-11-04 10:50 <cedk> zxq9: it matches the current schema | ||
| 2011-11-04 10:50 <zxq9> nicoe: Oh, haha. Nice. Thank you. | ||
| 2011-11-04 10:51 <zxq9> cedk: No, it doesn't. | ||
| 2011-11-04 10:51 <zxq9> cedk: Spellings are very complex. I mentioned this before, and making 3-languages to represent just Japanese does not work well. | ||
| 2011-11-04 10:51 <cedk> zxq9: I don't speak about spelling | ||
| 2011-11-04 10:51 <zxq9> Each element of the address must be searchable in hiragana, katakana, roman letters and kanji. | ||
| 2011-11-04 10:52 <cedk> zxq9: I speak about database structure ! | ||
| 2011-11-04 10:52 <cedk> zxq9: that's must be managed with the translation feature | ||
| 2011-11-04 10:52 <zxq9> And we have country, prefecture, municipality, city, town, village, neighborhood, number-clock, bunch, building name, building number, and room number fields. This is more than Tryton has room for. | ||
| 2011-11-04 10:53 <cedk> zxq9: what city, town and village are not the same thing? | ||
| 2011-11-04 10:53 <zxq9> The common solution is to just lump municipality, city and town together, then lump village and neighborhood, etc to make things fit. | ||
| 2011-11-04 10:54 <zxq9> But this makes searching bad, and does not model the reality at all -- which makes mapping very difficult. | ||
| 2011-11-04 10:54 <zxq9> city, town and village can all be different for the same address. | ||
| 2011-11-04 10:54 <zxq9> And places like Ishikawa prefecture, Osaka and especially Tokyo have MANY layers to the address. | ||
| 2011-11-04 10:54 <cedk> zxq9: so you don't use the right english name for you concept | ||
| 2011-11-04 10:54 <zxq9> So many that often people just skip some fields when writing but because of the post code the mail people know what you mean. | ||
| 2011-11-04 10:55 <zxq9> (usually) | ||
| 2011-11-04 10:55 <zxq9> No, a "city" in English can mean many things. Consider Macau or Hong Kong. | ||
| 2011-11-04 10:55 <zxq9> Or ancient Athens. | ||
| 2011-11-04 10:56 <zxq9> Anyway, there are some region ideas in Japan and China that do not have exact words in English. And this is part of the addressing problem. | ||
| 2011-11-04 10:56 <cedk> zxq9: I don't see at all all thos fields in https://secure.wikimedia.org/wikipedia/en/wiki/Japanese_addressing_system | ||
| 2011-11-04 10:58 <zxq9> Look at the part of the article titled "Address parts". This is not 100% accurate, because where it is talking about wards (ku), it doesn't mention that within a ky you can have a gun, and within a gun you can have a cho, and within a cho you can have a mura *and* a son in some cases. They are not exclusive. | ||
| 2011-11-04 10:59 <zxq9> My own address has ken, ku, shi, gun, son, kinjo, banchi, building number, room number. | ||
| 2011-11-04 11:00 <nicoe> The real question is why do you need to split those fields ? | ||
| 2011-11-04 11:00 <zxq9> Anyway, we still need option for street names. | ||
| 2011-11-04 11:01 <nicoe> Are you searching by 'mura' or 'son' ? | ||
| 2011-11-04 11:01 <zxq9> nicoe: Because we are using SQL calls from another program to tie this to mapped locations. | ||
| 2011-11-04 11:03 <zxq9> nicoe: Search must be enabled for any level, not just mura or son. Sometimes usually mura and son are the same thing, but not cho. | ||
| 2011-11-04 11:04 <nicoe> Japan should revise its system if 'sometimes mura and son are the same thing but not cho' :D | ||
| 2011-11-04 11:04 <zxq9> lol | ||
| 2011-11-04 11:05 <zxq9> There is a lot of history behind place names here... that is why things are complex. And spellings are radically non-standard for old names, which is why we have to support search in three writing systems. | ||
| 2011-11-04 11:05 <zxq9> Actually, most software completely ignores this problem -- and most users just get angry all the time here and do things by hand instead because of this. | ||
| 2011-11-04 11:06 <nicoe> Anyway it looks like a specific use for you ... Other companies in japan can probably use the party.address as is | ||
| 2011-11-04 11:06 <zxq9> Other companies just "deal with it" and survive with imperfect solutions. | ||
| 2011-11-04 11:07 <zxq9> Ours is uniquely user friendly, just a little more complex to model initially. | ||
| 2011-11-04 11:07 <zxq9> But that is the value -- not ignoring problems like this make really nice things possible for the user end. | ||
| 2011-11-04 11:08 <cedk> zxq9: I find it is difficult to solve a problem which is not clearly defined | ||
| 2011-11-04 11:08 <cedk> zxq9: a problem definition that contains "sometimes" doesn't have a solution | ||
| 2011-11-04 11:09 <bechamel> cedk: sometimes = not required | ||
| 2011-11-04 11:10 <cedk> bechamel: sometimes means fuzzy | ||
| 2011-11-04 11:10 <zxq9> cedk: Proper modeling of addresses here isn't impossible. It just requires adding 3 more fields to the depth of addresses, and then treating most of the fields as a 3-element array. | ||
| 2011-11-04 11:10 <cedk> zxq9: for you character, the solution is the translation | ||
| 2011-11-04 11:11 <cedk> zxq9: so if it is just adding 3 fields, it is easy to extend address model | ||
| 2011-11-04 11:11 <cedk> zxq9: and for searching on the three caracters set just override the search method of address to search on the 3 languages | ||
| 2011-11-04 11:12 <cedk> ACTION Japan solved | ||
| 2011-11-04 11:12 <zxq9> cedk: adding three languages to represent asingle language is inelegant, to say the least -- and winds up confusing uers who accidentally select "katakan" as a language preference and suddenly get an all-English interface instead. | ||
| 2011-11-04 11:13 <cedk> zxq9: for me it is the best solution | ||
| 2011-11-04 11:14 <cedk> zxq9: and it simplify the screen as translation is managed at the client side | ||
| 2011-11-04 11:15 <cedk> zxq9: also if you don't like 3 languages so rename lanugage into character set | ||
| 2011-11-04 11:15 <nicoe> It's the same concept "translated" in different spelling | ||
| 2011-11-04 11:15 <zxq9> cedk: But we need language also. We have German, Russian, Japanese and English users currently. | ||
| 2011-11-04 11:15 <nicoe> When you say Japanase, which japanese ? | ||
| 2011-11-04 11:16 <cedk> zxq9: yes it is the same | ||
| 2011-11-04 11:16 <zxq9> nicoe: What do you mean? | ||
| 2011-11-04 11:16 <cedk> zxq9: i hope for you that you don't write english into the 3 sets of characters | ||
| 2011-11-04 11:16 <zxq9> cedk: ? | ||
| 2011-11-04 11:18 <cedk> zxq9: if your 3 sets of char are not language, I understand that you want also to write english name like 'New-York" into the 3 sets of char | ||
| 2011-11-04 11:19 <nicoe> zxq9: When you say that you have japanese users, which spelling do they use ? | ||
| 2011-11-04 11:21 <zxq9> nicoe: All three are required for things like printing government forms. Names for people and companies (and sometimes addresses, depending on the form) are always required to input katakan or hiragana above the kanji, and sometimes Romanized spelling below that. | ||
| 2011-11-04 11:22 <zxq9> cedk: A name like "New York" would only occupy the Roman letter line, and remain as is. But some specific international place names, like England, for example, are written three or four ways correctly on different documents. | ||
| 2011-11-04 11:23 <cedk> zxq9: for me, it is definitly 3 languages | ||
| 2011-11-04 11:23 <zxq9> But we can reduce to three consistently by always converting hiragana to katakana, since they are the same values, only a script difference. | ||
| 2011-11-04 11:25 <cedk> zxq9: so hiragana and katakana are just formatting | ||
| 2011-11-04 11:28 <zxq9> cedk: If we treat them that way, yes. Of course, they are different unicode characters, but its easy to cast beteen them because they are just different ound spellings. | ||
| 2011-11-04 11:29 <zxq9> cedk: kanji and romaji is where it is tricky, and kanji is impossible to cast into or out of accurately. | ||
| 2011-11-04 11:31 <cedk> zxq9: yes so it is a different language | ||
| 2011-11-04 11:33 <zxq9> lol | ||
| 2011-11-04 11:40 <zxq9> Is there any reason why the admin user doesn't see the thousands separator but a normal user does? Both have same language setting, etc. | ||
| 2011-11-04 11:42 <cedk> zxq9: no | ||
| 2011-11-04 11:42 <cedk> zxq9: admin is like any users | ||
| 2011-11-04 11:47 <udono> zxq9: cedk: for me the thousands-separator should not be shown on integer fields. Or if there is need for this, it should be possible to disable. | ||
| 2011-11-04 11:48 <zxq9> udono: A possible way (ugly, temprary kludge) is to cast before/after operation or passing the value somewhere else to make it not appear. | ||
| 2011-11-04 11:49 <zxq9> udono: This raises new problems with bad input handling, though. | ||
| 2011-11-04 11:50 <cedk> udono: why, you got a formating of number I don't see why it should be different if it is an int or a float | ||
| 2011-11-04 12:03 <udono> cedk: Some numbers like zip numbers, account numbers are usually not shown with thousand separator, when represented by integer. Maybe the true problem is (mentioned by zxq9) the handling of bad input. This seems better solved with domains for simple fields. | ||
| 2011-11-04 12:04 <bechamel> udono: aren't zip and account numbers Char fields ? | ||
| 2011-11-04 12:04 <yangoon> udono: zip must not be a number | ||
| 2011-11-04 12:05 <zxq9> udono: I just tested the ugly casting method. If a field that needs to show no separator is Char type, any logic with that field must wrap it in int() and return with str(int()). | ||
| 2011-11-04 12:05 <zxq9> udono: If the user inputs something like "blue" which is legal in a Char field, but not legal when an operation involving the int() cast happens, Tryton throws an ugly popup, but won't crash. | ||
| 2011-11-04 12:06 <zxq9> Just the operation fails. Not a good solution, but a manageable kludge. | ||
| 2011-11-04 12:06 <zxq9> Unless you have a lot of fields like this. Then that would be a really bad way. | ||
| 2011-11-04 12:09 <yangoon> ACTION configurable display of thousands separator per field would be a good feature | ||
| 2011-11-04 12:10 <cedk> zxq9: catch ValueError except and raise a UserError instead | ||
| 2011-11-04 12:10 <cedk> yangoon: why? | ||
| 2011-11-04 12:10 <cedk> udono: so you don't have any example | ||
| 2011-11-04 12:11 <yangoon> cedk: because you can indeed wish to display this separator in some fields, in others not | ||
| 2011-11-04 12:11 <cedk> yangoon: but why? | ||
| 2011-11-04 12:11 <cedk> yangoon: a number is a number | ||
| 2011-11-04 12:12 <yangoon> if you are handling financial numbers, you perhaps will prefer display with separator | ||
| 2011-11-04 12:12 <cedk> yangoon: what do you mean? | ||
| 2011-11-04 12:12 <yangoon> there could be other usage of int fields, where you don't wishj | ||
| 2011-11-04 12:12 <yangoon> lotto numbers:D | ||
| 2011-11-04 12:12 <cedk> yangoon: not numbers | ||
| 2011-11-04 12:12 <yangoon> do you know what I mean by lotto? | ||
| 2011-11-04 12:12 <cedk> yangoon: it is a series of number | ||
| 2011-11-04 12:13 <cedk> yangoon: yes and it is not a big number | ||
| 2011-11-04 12:13 <cedk> next example… | ||
| 2011-11-04 12:14 <yangoon> cedk: depends, there are different lotto species | ||
| 2011-11-04 12:14 <cedk> ACTION tell me your need, I will explain how to do without | ||
| 2011-11-04 12:14 <yangoon> cedk: quantity, you could prefer to national preferneces to have them without separator | ||
| 2011-11-04 12:15 <cedk> yangoon: there is a formating for currencies | ||
| 2011-11-04 12:16 <cedk> I agree that it will be good to allow currency formating in the client but it is a complex task (I already tried) | ||
| 2011-11-04 12:18 <udono> cedk: When I think about, it is realy the input validation aspect of integer we would like to use. But as said, this aspect would be more flexible solved with domains for char, text, integer, ... fields. | ||
| 2011-11-04 12:19 <udono> bechamel: yangoon: I am comfortable with zip and account numbers represented as Char in tryton. | ||
| 2011-11-04 12:19 <yangoon> cedk one more;): room number, which is really a *number*, not a string | ||
| 2011-11-04 12:19 <yangoon> I never saw a panel indicating romm number 1.000 | ||
| 2011-11-04 12:19 <cedk> yangoon: also I always find difficult to work with other language/currency number formating so I even don't think it is a good idea to have in the client currency formatting | ||
| 2011-11-04 12:19 <cedk> yangoon: no room numbers could be: 15A | ||
| 2011-11-04 12:20 <cedk> yangoon: next | ||
| 2011-11-04 12:20 <bechamel> :) | ||
| 2011-11-04 12:20 <cedk> udono: agree someking of pattern matching will be great | ||
| 2011-11-04 12:20 <cedk> udono: like for dates | ||
| 2011-11-04 12:22 <zxq9> cedk: About the exception. Very nice. Ty. | ||
| 2011-11-04 12:23 <zxq9> Ah, about separators, if it were configurable per field it would be nice (but not necessary). This is another Japanese thing, of course. Counting here isdone in periods of four, not three, but some things are counted in periods of three. | ||
| 2011-11-04 12:24 <zxq9> So most of the time counting goes like this: 10,0000,0000. But for some things like this 1,000,000,000. | ||
| 2011-11-04 12:24 <zxq9> It is a very minor thing, though. | ||
| 2011-11-04 12:24 <cedk> zxq9: WTF, it has no utilities to use a convention if it is not always used | ||
| 2011-11-04 12:25 <zxq9> cedk: That would be true, if we lived in a world ruled by computers, not people (who are crazy, fickle and expect the most arbitrary things). | ||
| 2011-11-04 12:25 <cedk> zxq9: no, formatting rules doesn't come from computers | ||
| 2011-11-04 12:26 <zxq9> cedk: Anyway, this is cultural with a very long history to it. The language of Japanese itself formats numbers this way. | ||
| 2011-11-04 12:26 <cedk> zxq9: it has an utility but it seems Japanese did not understand it | ||
| 2011-11-04 12:26 <cedk> zxq9: I guess the Japan takes the number to arabs | ||
| 2011-11-04 12:26 <zxq9> lol | ||
| 2011-11-04 12:26 <cedk> zxq9: so not long specifici history | ||
| 2011-11-04 12:26 <nicoe> zxq9: In europe there was like a thousand different way to count and measure ... then Napoleon arrived with the metric system and invaded everything. It was so good even the english use it now. | ||
| 2011-11-04 12:26 <zxq9> Actually its long before that, but happens to be periods of 4 | ||
| 2011-11-04 12:27 <cedk> zxq9: or did they also have different charset to write numbers ? | ||
| 2011-11-04 12:27 <zxq9> Yes, different charset for numbers. | ||
| 2011-11-04 12:27 <zxq9> With specific ones to huge numbers in several bases, actually. But that is mostly academic now. | ||
| 2011-11-04 12:27 <zxq9> But in common speech base-10 counting is done in periods of 4, not 3. | ||
| 2011-11-04 12:28 <cedk> zxq9: yes we also get this, it is named float point representation | ||
| 2011-11-04 12:29 <zxq9> You can also drop leading zeroes between periods when writing using Japanese characters as separators (instead of commas). This is very common with huge numbers. | ||
| 2011-11-04 12:29 <zxq9> Sort of the way IP6 works. | ||
| 2011-11-04 12:29 <nicoe> funny | ||
| 2011-11-04 12:29 <cedk> ACTION Japan needs to come to the 20 century | ||
| 2011-11-04 12:30 <zxq9> So we need to roll IP6 back. | ||
| 2011-11-04 12:30 <zxq9> because its not very 21st century. | ||
| 2011-11-04 12:30 <zxq9> Anyway, notations are arbitrary. Providing hooks to switch between them shouldn't be any more unusual than providing type casting functions. | ||
| 2011-11-04 12:31 <zxq9> I think the only real universal is binary. Its what our computers speak, anyway. | ||
| 2011-11-04 12:31 <cedk> zxq9: I say that especially about grouping that depends on xxx | ||
| 2011-11-04 12:31 <zxq9> Anyhow, this conversation demonstrates how deep unintentional cultural bias can extend, I think. | ||
| 2011-11-04 12:32 <cedk> zxq9: I don't care about missing 0 but I don't think there is any standard formating lib that allow that | ||
| 2011-11-04 12:32 <cedk> zxq9: no the real issue with Japan is the rules that has no rules | ||
| 2011-11-04 12:32 <zxq9> There are some Japanese ones that do, particularly for financial systems and video game models. But I doubt they see any use outside of japan. | ||
| 2011-11-04 12:33 <zxq9> cedk: There are rules to things. Domains of use, etc. | ||
| 2011-11-04 12:34 <zxq9> cedk: We're not screaming about how dumb Germans are for having three ways to write "ss" and two ways to note umlauts. Or Spanish computer users for frequently omitting ~. | ||
| 2011-11-04 12:34 <udono> zxq9: +1 :-) | ||
| 2011-11-04 12:34 <zxq9> User expectations trump all other considerations when it comes to everything but research software. And in this case "research software" == "software with no users" | ||
| 2011-11-04 12:35 <cedk> ACTION Japan looks like the England about metric system | ||
| 2011-11-04 12:35 <zxq9> cedk: Or America. And its still the only superpower. | ||
| 2011-11-04 12:36 <zxq9> So, my challenge is how to make the interface meet my users' crazy expectations -- as non-standard as they are. Humans are just non-standard and they all suck. | ||
| 2011-11-04 12:36 <zxq9> And every programming language and operating system sucks in exactly the same way. | ||
| 2011-11-04 12:36 <zxq9> (^.^) | ||
| 2011-11-04 12:37 -!- sharoon(~sharoon@187.35.109.225) has left #tryton | ||
| 2011-11-04 12:37 <cedk> zxq9: so what is the rule about grouping numbers? | ||
| 2011-11-04 12:38 <zxq9> cedk: Just depends on the use case. | ||
| 2011-11-04 12:38 <cedk> zxq9: what is the rules of use case | ||
| 2011-11-04 12:38 <cedk> zxq9: if there is a rules, you can explain it or there is no rules | ||
| 2011-11-04 12:38 <zxq9> lol | ||
| 2011-11-04 12:39 <zxq9> There is not a law signed by a committee about it, but there are common conventions. | ||
| 2011-11-04 12:39 <cedk> zxq9: if you can not explain then there is no rules | ||
| 2011-11-04 12:39 <zxq9> For common tabulation either way is acceptable. For formal reporting periods of 4 are most common, especially in finance. And for presentations using kanji separators is most common, unless leaving lots of zeroes for emphasis. | ||
| 2011-11-04 12:40 <zxq9> Most software developed in the US, however, does not have a concept of flexible periods or kanji separators, so users can tolerate periods of 3 with commas. | ||
| 2011-11-04 12:41 <zxq9> Basically, any number field that is likely to have a result > 10E9 should be in periods of 4. | ||
| 2011-11-04 12:41 <zxq9> Because it is very difficult to read a number in your head converting many periods of 3 into periods of 4. | ||
| 2011-11-04 12:42 <zxq9> So, general rule: Default to 4. 3 is OK for small numbers, 4 always for large values. Kanji separators for formal reporting. | ||
| 2011-11-04 12:42 <zxq9> Not very mysterious, especially if you live here it makes sense. | ||
| 2011-11-04 12:43 <zxq9> Anyway, being a cultural quirk, it is a lot like trying to explain slang grammar without being trained in linguistic instruction: It makes perfect sense to you and your friends, but diagramming the semantics is suddenly not very clean. But yet it works. | ||
| 2011-11-04 12:43 <cedk> zxq9: so I really suggest you to drop the 3 periods as it is not so useful | ||
| 2011-11-04 12:44 <zxq9> And most native developed software does. | ||
| 2011-11-04 12:44 <cedk> zxq9: so you can have 4 periods in Tryton | ||
| 2011-11-04 12:45 <zxq9> But ah... here is the exception! Haha... when delivering reports to foreign parties, like on inter-governmental projects and things. | ||
| 2011-11-04 12:47 <cedk> zxq9: but number formatting depends of the language so no problem | ||
| 2011-11-04 12:49 <zxq9> cedk: Ah, this is very nice. | ||
| 2011-11-04 13:43 <zxq9> What am I doing wrong here: <notebook tabpos="up" colspan="6"> ... </notebook> ? Without 'tabpos="up"' everything works fine. I get Invalid XML in view error. | ||
| 2011-11-04 13:49 <cedk> zxq9: tabpos is removed in 2.2 | ||
| 2011-11-04 13:51 <zxq9> Ah. | ||
| 2011-11-04 13:51 <zxq9> I was referencing the website docs -- still just 2.0. Hehe! | ||
| 2011-11-04 13:52 <zxq9> Is there another way to get the same effect, or was the feature just removed completely? | ||
| 2011-11-04 13:53 <cedk> zxq9: it is a configuration of the client | ||
| 2011-11-04 13:53 <cedk> https://bugs.tryton.org/issue2135 | ||
| 2011-11-04 13:54 <zxq9> oic | ||
| 2011-11-04 13:54 <zxq9> ty | ||
| 2011-11-04 14:15 -!- hedayat(~hedayat@fedora/hedayatvk) has left #tryton | ||
| 2011-11-04 14:18 <hedayat> Hi all! | ||
| 2011-11-04 14:18 <hedayat> I have a problem with tryton access control settings | ||
| 2011-11-04 14:18 <hedayat> Can anybody help me? | ||
| 2011-11-04 14:18 <hedayat> :P | ||
| 2011-11-04 14:19 <zxq9> I haven't learned much about that yet myself, but there are some very knowledgable (and helpful) people here. | ||
| 2011-11-04 14:19 <zxq9> But sometimes it takes a while to get a response. (^.^) | ||
| 2011-11-04 14:20 <hedayat> zxq9: :) Thanks | ||
| 2011-11-04 14:20 <cedk> hedayat: don't ask to ask, just ask | ||
| 2011-11-04 14:20 <hedayat> cedk: :) OK | ||
| 2011-11-04 14:21 <hedayat> I have installed Tryton, and I want to restrict access to Party information for all users except a single group | ||
| 2011-11-04 14:22 <hedayat> I go to Model Access page and add a rule which doesn't allow anything (even read access) to Party model | ||
| 2011-11-04 14:22 <cedk> hedayat: you want to restrict access to party, this is a big change as party is used wildly in the system | ||
| 2011-11-04 14:23 <hedayat> Then I try to access Party page with a non-admin user, it gives an error that you cannot read that document, | ||
| 2011-11-04 14:23 <cedk> hedayat: yes you must create a default model access and an other one for the specific group | ||
| 2011-11-04 14:23 <hedayat> I press OK but it brings the error dialog again and again. I'm forced to kill tryton in this case! | ||
| 2011-11-04 14:23 <cedk> hedayat: yes it is a know issue, you should also hide menu for it | ||
| 2011-11-04 14:24 <hedayat> cedk: Aha! hmmm sorry, how can I hide a specific menu entry? (sorry I'm a newbie in the Tryton world :P) | ||
| 2011-11-04 14:24 <cedk> http://codereview.tryton.org/165003/ | ||
| 2011-11-04 14:25 <cedk> hedayat: this is the patch that prevent the inifit loop | ||
| 2011-11-04 14:25 <cedk> hedayat: to hide a menu, you must add groups to it | ||
| 2011-11-04 14:25 <hedayat> cedk: And please let me know if there are any online documentation for tryton since I didn't find much except the installation documentation and the | ||
| 2011-11-04 14:25 <hedayat> wiki | ||
| 2011-11-04 14:27 <cedk> hedayat: once a menu has a group, it is hidden for all others | ||
| 2011-11-04 14:28 <cedk> hedayat: there is doc.tryton.org but not sure if it talk about that | ||
| 2011-11-04 14:28 <hedayat> cedk: Thanks a lot for the info. let me see if I can do it | ||
| 2011-11-04 14:31 <cedk> hedayat: becareful that playing with access, you can break your setup by preventing your self to access some part of the software | ||
| 2011-11-04 14:31 <zxq9> O.o | ||
| 2011-11-04 14:31 <hedayat> cedk: Yes! Thanks :) | ||
| 2011-11-04 14:36 <hedayat> cedk: Thanks a lot. It worked. Also thank you for the patch. | ||
| 2011-11-04 14:36 <hedayat> :) | ||
| 2011-11-04 14:37 <hedayat> And yes, the document in the doc.tryton.org is very limited. I've already seen that. | ||
| 2011-11-04 14:38 <cedk> hedayat: best doc is the code :-) | ||
| 2011-11-04 14:39 <zxq9> hedayat: He's right about that. It just takes a bit to get familiar with it at first. | ||
| 2011-11-04 14:42 <cedk> any way, help is welcome to complete the current doc | ||
| 2011-11-04 14:42 <hedayat> cedk: :) | ||
| 2011-11-04 14:42 <hedayat> cedk: Yes, I'm thinking about that. I might find some people who are interested to contribute in that part | ||
| 2011-11-04 14:43 <hedayat> zxq9: so maybe I should start reading it if I decided to seriously work on it | ||
| 2011-11-04 14:44 <zxq9> hedayat: Yep. But the best way to get familiar is to write a toy module or two to play with it. Then you really start seeing how things go together. | ||
| 2011-11-04 14:45 <hedayat> zxq9: Thanks for the suggestion. I'll do that | ||
| 2011-11-04 14:45 <zxq9> hedayat: Try the "hello world" module from the wiki howto. Just remember to not include the icon tag in the XML form (it'll do bad things if you don't have the party module installed, I think). | ||
| 2011-11-04 14:47 <hedayat> zxq9: :) OK! | ||
| 2011-11-04 14:48 <zxq9> If you do that one, then between referencing doc.tryton.org, docs.python.org (especially the language definition and library), and reading the code you can do a lot. Even if you never used Python before. | ||
| 2011-11-04 14:54 <cedk> hedayat: I suggest also the training mqueue repo | ||
| 2011-11-04 14:54 <cedk> http://hg.tryton.org/2.0/training/ | ||
| 2011-11-04 14:55 <cedk> it is not yet updated to 2.2 but it cover step by step almost all the principal concepts | ||
| 2011-11-04 15:05 <hedayat> cedk: Thanks, I'll look into it | ||
| 2011-11-04 15:05 <hedayat> Another question, how can I customize the search operation?! It looks very limited! For example, in the Party/Parties there is only a | ||
| 2011-11-04 15:05 <hedayat> search box | ||
| 2011-11-04 15:06 <hedayat> Even if I write a few characters in the middle of a party name, it doesn't find it! | ||
| 2011-11-04 15:06 <hedayat> For example I search for et | ||
| 2011-11-04 15:06 <hedayat> but it doesn't find "Tet4" | ||
| 2011-11-04 15:07 <hedayat> And isn't there any way for me to specify in which fields should it search? | ||
| 2011-11-04 15:11 <bechamel> hedayat: type the name of the field | ||
| 2011-11-04 15:11 <bechamel> hedayat: the entry will auto-complete it | ||
| 2011-11-04 15:14 <hedayat> bechamel: Thanks! What about looking for words containing some characters, e.g. searching for 'st' and finding 'test'? Is it possible? | ||
| 2011-11-04 15:15 <bechamel> hedayat: you have to prefix the search with "%" | ||
| 2011-11-04 15:15 <bechamel> it's the wildcard caracter in slq | ||
| 2011-11-04 15:15 <bechamel> *sql | ||
| 2011-11-04 15:15 <hedayat> bechamel: Thanks! | ||
| 2011-11-04 15:16 <bechamel> hedayat: but it may be slow on big tables | ||
| 2011-11-04 15:17 <hedayat> bechamel: OK! | ||
| 2011-11-04 15:17 <hedayat> :) | ||
| 2011-11-04 15:20 <bechamel> hedayat: and of course you can combine several query | ||
| 2011-11-04 15:20 <bechamel> hedayat: "name: > T or name: < U" | ||
| 2011-11-04 15:24 <hedayat> bechamel: I'm trying this one but doesn't work: Name: >Tet or Name: <T | ||
| 2011-11-04 15:24 <hedayat> bechamel: it is converted to: Name: >"Tet OR" Name: <T | ||
| 2011-11-04 15:24 <hedayat> :P | ||
| 2011-11-04 15:24 <bechamel> hedayat: hum | ||
| 2011-11-04 15:25 <bechamel> hedayat: you have found a bug | ||
| 2011-11-04 15:27 <hedayat> bechamel: OK! I think I found another one too: | ||
| 2011-11-04 15:27 <hedayat> bechamel: write "Name: >T or Name: <U" and press enter | ||
| 2011-11-04 15:27 <hedayat> bechamel: then delete T | ||
| 2011-11-04 15:28 <hedayat> An exception is thrown | ||
| 2011-11-04 15:28 <hedayat> ! | ||
| 2011-11-04 15:31 <bechamel> hedayat: I cannot reproduce it | ||
| 2011-11-04 15:32 <bechamel> hedayat: oh yes, I was missing the "or" | ||
| 2011-11-04 15:32 <bechamel> hedayat: can you fill a bug ? | ||
| 2011-11-04 15:32 <hedayat> bechamel: Yes, I'm going for it | ||
| 2011-11-04 15:33 <bechamel> thx | ||
| 2011-11-04 15:36 <hedayat> bechamel: https://bugs.tryton.org/issue2262 | ||
| 2011-11-04 15:36 <hedayat> Oops,let me provide more info there about how to reproduce it | ||
| 2011-11-04 16:34 -!- hedayat(~hedayat@fedora/hedayatvk) has left #tryton | ||
| 2011-11-04 21:47 <cjbarnes18> cedk: hello o/, I have been looking at your suggestion in codereview 167007. | ||
| 2011-11-04 21:48 <cjbarnes18> cedk: it seems to me that we can either require lock for cron, or detect a lock and continue if found. | ||
| 2011-11-04 21:48 <cjbarnes18> cedk: I am not sure which would be preferable. | ||
| 2011-11-04 21:55 <cjbarnes18> cedk: the usual exception that occurs seems to be triggered by the test for the presence of the ir.cron module, would it be better to sanitise this? | ||
| 2011-11-04 21:55 <cjbarnes18> cedk: or maybe even set a maintenance property for the database during each of the maintenance functions that we check for. | ||
| 2011-11-04 21:55 <cjbarnes18> would it be appropriate to create a new property on the pool instances? | ||
| 2011-11-04 22:03 <cedk> cjbarnes18: I preferp to use the lock | ||
| 2011-11-04 22:05 <cjbarnes18> cedk: ok, I am guessing it should not block? | ||
| 2011-11-04 22:06 <cedk> cjbarnes18: I think it should | ||
| 2011-11-04 22:08 <cjbarnes18> that would stop cron for other databases while it it | ||
| 2011-11-04 22:08 <cjbarnes18> is waiting for the lock? | ||
| 2011-11-04 22:08 <cjbarnes18> same effect as setting CONFIG | ||
| 2011-11-04 22:11 <cjbarnes18> cedk: as far as I can tell at least anyway... | ||
| 2011-11-04 22:43 <cedk> cjbarnes18: ok I mean try to get the lock in the cron for a database, if did not succeed skip it | ||
| 2011-11-04 22:44 <cedk> cjbarnes18: but keep the lock, during the cron process | ||
| 2011-11-04 22:44 <cedk> cjbarnes18: but of course don't wait to get the database lock | ||
| 2011-11-04 22:45 <cjbarnes18> cedk: ok, thanks for your help, will have a go. | ||
| 2011-11-04 23:41 <hoRn> dumb at evening again :-( | ||
| 2011-11-04 23:45 <hoRn> whats wrong with: product_obj.search_read([('id', 'in', template['products']), ('quantity', '>', 0.0)]) - get all products with no quantity | ||
| 2011-11-04 23:58 <hoRn> is there a limitation for function_fields in search_read? | ||
| 2011-11-04 23:59 <hoRn> never used search_read before ... |
Generated by irclog2html.py 2.17.3 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!
