IRC logs of #tryton for Tuesday, 2013-04-09 #tryton log beginning Tue Apr 9 00:00:09 CEST 2013
plantianHey guys when printing opens open office instead of printing to printer is that a client side option or something I could configured from a wizard?09:36
plantianIt seems that print and report keywords do the same thing.10:38
cedkplantian: direct print depends on the OS10:43
plantiancedk: Well I'm trying to set it up on Linux and Mac.10:44
plantiancedk: There used to be a way to configure the command line call that printed right?10:44
cedkplantian: it doesn't work on linux nor MacOS because they don't have a API for it10:45
cedkplantian: yes but it was removed in favor of xdg-open for linux and /usr/bin/open for MacOS10:46
plantiancedk: And xdg-open and open don't support direct printing?10:47
cedkplantian: no10:48
plantiancedk: ok thanks, can you think of any other way I could make it possible to get direct printing?10:50
cedkplantian: you can tune xdg-open to do it always for a specific extension10:51
plantiancedk: The downside to that is that opening other open office documents on that machine will just print them right?10:52
cedkplantian: yes but you can use an other extension10:53
cedkplantian: but a good solution will be to have a API on those OS for printing11:05
plantiancedk: Yeah, I think I had something working before in 1.8.  I must have hacked something together on the mac with File Options.11:09
plantianI have wizard that is a faster way to create a sale, sort of like a register, and after it was done it auto printed.11:09
cedkplantian: yes before the client managed a extension file register11:12
cedkplantian: but it was very simple and it required to duplicate the information with what the OS has11:12
cedkplantian: so I really think you should try with a custom extension like: .odt_print11:13
plantianRight, and change the file path in the xml and module ?11:14
plantiancedk: The mac client is almost more important but maybe there is a way to use a script wrapper to create an app that just prints the file in the same way.11:15
cedkplantian: I guess11:16
plantianI guess I don't have a lot of other ideas.11:18
rpitA question on products: the list-price is requiered, but allowed to be "0.0". Is this intended?13:29
corrorpit: yes, it's been discussed on the mailing list but I don't find the thread13:32
corrorpit: here we are:!topic/tryton/y8azeglzE-A13:34
rpitcorro: Thank you, that's good for me! But I think then there's an error in the import:13:37
rpitres = value and Decimal(value) or None will result in None for a "0.0"-value and cannot be imported13:38
cedkrpit: yes15:39
cedkrpit: indeed, I don't think there is an issue because value is a string15:40
rpitcedk: But the string "0.00" results in "None" and will not satisfy the required constraint15:41
cedkrpit: heu, yes15:42
rpitcedk: To be analogue to the GUI the import had to distinguish between null and zero15:43
cedkrpit: it should be a if-else test15:43
rpitcedk: But a patch would change the behaviour for all numeric fields.15:45
cedkrpit: don't understand15:45
rpitcedk: on import an emplty field behaves equal a zero-value: They don't pass the required constraint. After patching the zero-value would pass it.15:47
cedkrpit: '0' should become 0 not None15:48
rpitcedk: yes, I agree. But we should know, that the behavouier changes concerning the required constraint15:49
rpitcedk: To explain: The create-method of a product-template accepts a record with a list price Decimal(0), but reject it with the list price "None".15:56
cedkrpit: yes I know, it is the expected behavior15:57
rpitcedk: now the import_data transfers "0.0" to "None" and the following create rejects the record. If we change the import, it will accept the same record.15:57
cedkrpit: yes15:58
rpitcedk: okay, let's patch it15:58

Generated by 2.11.0 by Marius Gedminas - find it at!