Data export to OpenOffice.org Calc

It was already possible to export data from the GTK client to MS Excel in a similar way to the CSV export. I've implemented this export functionality for OpenOffice.org Calc. The code is in this bug report: https://bugs.launchpad.net/bugs/399278

Update: Tiny refused to include this functionality in the GTK client but the KDE client did it!

product_price_update v1.05

Please note that product_price_update has been moved to extra-addons. This new version doesn't update the product if the newly calculated price == old price.
The new behavior is useful for synchronizing applications that check the last write date. Maybe the speed has been improved, too.

For Kubuntu users

Have you ever wondered why some of the labels are left untranslated in the GTK client? Install the language-pack-gnome-YOURLANG-base package...

base_report_unicode v1.1

The base_report_unicode module has been updated to work with the new report engine that's in v5.0 for some weeks now. The module has been moved to trunk-extra-addons from the community-addons.

Update: This module is now in the 5.0-extra branch.

Running OpenERP on Ubuntu 9.04

The OpenERP server has some compatibility problems because it works only with python 2.5 and the deprecated PyXML library. Ubuntu 9.04 has python 2.6 as default and a broken PyXML (python-xml) package. Depedencies on the deprecated PyXML should be removed from OpenERP, anyway. The following instructions require more than basic level linux skills.

1. Solve the python 2.5 problem: Make sure you have python2.5 installed. sudo apt-get install python2.5 Then you have to be sure that the server starts with python2.5, not python (that's the 2.6 version). So if you have an openerp-server script, change the 'exec /usr/bin/python ./openerp-server.py' to 'exec /usr/bin/python2.5 ./openerp-server.py'
2. Solve python-xml. A file is missing from the python-xml package, boolean.so .That has to be compiled from source and copied to /usr/lib/python2.5/site-packages/oldxml/_xmlplus/utils . The instructions for compiling would be too long to describe here; If you write me here or on the irc channel, I'll send you my already compiled version or describe the necessary steps in detail.

p.s. I've just created a blueprint for python 2.6 support.

Update: Finally the deprecated libs were removed, the latest bzr 5.0 and trunk work on new Ubuntus.

New module: base_report_unicode

The final solution to the unicode printing problem many times mentioned in this blog! Simply install this module and your reports will have the truetype fonts needed. That's all, no patching, no tinkering with reportlab and the fonts:)
I've uploaded this module to the community addons mentioned in the previous post.

Where are the modules?

Just a reminder how the OpenObject module repositories are set up.
There are 3 categories with 3 levels of code quality review requirements:
The stable 5.0 official addons
The development official addons
are the modules bundled with OpenERP and these represent the core functionality. The OpenERP Quality Team is responsible.
The stable 5.0 extra addons
The development extra addons
is a large collection (~300) of modules from many contributors. They are usually of good quality but the strict review process is not needed. Members of the OpenERP Commiters team can upload here. OpenERP Commiters are more experienced users & developers.
The community addons
is a new repository. This is going to be a repository where everyone can upload his/her modules if he wants to make it publicly available. The OpenERP Community team is open to everyone.

Easier unicode reports

Some of you might remember the unicode reports problem that was my first post on this blog. Now I made a better solution. This automatically replaces the old fonts' names with the unicode ones in memory. The report files don't have to be modified.
The wiki mentioned in the original post has been updated with the new instructions.

New module: product_price_update

I have rewritten the extra-addons/product_listprice_upgrade module, it can be downloaded with 'bzr branch lp:~gdukai/openobject-addons/product_price_update'.

It has several improvements over the original:
-Possible to update any price type not just the list price.
-Correctly uses recursion and checks to update a price only one time even if parent and child categories are selected.
-Rewritten using the new osv_memory objects (the old module used wizard.interface).
-Corrects a menu duplication.

If you don't know what it is for, read my previous post. This module could also be interesting to see how the old type wizard looks like reimplemented in osv_memory.

Better price control

The basic setup of OpenERP has a very simple pricelist setup: manually set the list prices of the products and use them for the sales orders. Many companies use a cost price + margin% = list price formula. To work like this, we could easly modify the default public pricelist (sales pricelist) to be based on the cost price and add some percentage to that.
But this is usually not enough, for two reasons:

• The prices calculated by the sales pricelist can only be seen when creating new sales order lines. Nothing updates the list price field on the products.
• The sales prices change with every purchase because it changes the cost price they are based on. Many companies don't want to change prices every hour or so.

The solution: use the product_listprice_upgrade module in extra-addons. We need the original public pricelist that is based on the list price. Plus we have to create a new one of the type 'internal' and set it up to be based on the cost price + margin formula. The wizard in the listprice_upgrade module under the Pricelist menu will update the list price for the products we choose. This has to be run every time we decide to have new list prices.

p.s. There's a better module than product_listprice_upgrade, read this post.

The wiki is going to be deleted

As some of us have already noticed, the old wiki links that start with openerp.com are not valid any more. That's easy to solve, the wiki has moved to openobject.com/wiki, the links have to be corrected. The more important thing is that the wiki pages are going to be removed, so take a backup now if you need that content! Some of the wiki pages are copied to doc.openerp.com, some not. It depends on Tiny sprl to decide.

Securing web remote access

Today I had to set up remote access to the test database we are using. Both the GTK client and the Web client can be used over SSL (I didn't try Koo because it's not ported to OpenERP 5 yet). I chose to set up the Web client for two reasons: I've read in some forum posts that it's better for slow connection remote sites and because I needed real security after enabling connections from the wide Internet to my OpenERP server. As the Web client doesn't use SSL on it's own, an Apache server has to be set up with mod_proxy and mod_ssl. A description is in the documentiation. That's not enough! With this all the users are exposed to the Internet so I decided to require a certificate login for the browsers. With that only those can access the OpenERP Web client who received a client certificate from me. For this to work, a few more lines are needed in the apache config:
In the VirtualHost:

SSLCertificateKeyFile path/server.key
SSLCACertificateFile path/ca.crt
SSLVerifyClient require
SSLVerifyDepth 10

And the Proxy section:

Order deny,allow
Allow from all
SSLRequireSSL

Of course, the self-signed certificate authority, the server key and the client keys are all have to be set up correctly, that's a little more difficult...

The new wizards: osv_memory

With v5 a new wizard solution has appeared in OpenERP, the osv_memory objects. The good thing about them is that they behave like the other osv objects so we don't have to learn new tricks to use them. A good introduction can be found in this forum topic, in Fabien's post. The bad thing is that they also have some tricks and those are not documented. If you search the forums you'll find mostly questions not answers. In the source code, most of the wizards are still the old wizard.interface type, the new osv_memories are mainly used for module installation configuration dialogs. Despite these problems I'll stay with osv_memory and hopefully I'll never have to learn the old way:)

5.0 branches created today

This morning the new and long awaited 5.0 branches have appeared on launchpad. But it looks like the addons doesn't have a new branch yet. Take a look! I'm thinking of staying with the trunk, maybe the changes in the next version won't be so radical.

Function calculated fields with stored values

Function fields which store the calculations results are important to make function fields fast enough not only with test data but also with bigger databases. In v5 the recalculation of stored functions can be triggered by the changes (write, create) in other objects and that makes them really useful.
There's an example in account.invoice where the fields amount_untaxed, amount_tax and amount_total are computed by the same function, _amount_all. An shortened example:

'amount_total': fields.function(_amount_all, method=True, digits=(16,2), string='Total',
store={
'account.invoice.line': (_get_invoice_line, None, 20),
},),

This means that if an account.invoice.line changes, _get_invoice_line is invoked with the line's id. _get_invoice_line has to return an id of the main object, account.invoice. _amount_all will receive that id and compute the value to be stored in the field.

OpenERP vs SQL-Ledger

Now that OpenERP 5 is out a new webpage was launched where ERP solutions are compared. This gave me the thought to write about my own experience. As a developer and maintainer of a heavily customized SQL-Ledger/Lx-Office hybrid I can say that a comparison is not really possible. OpenERP is so much better that they are not in the same category... Now I can develop so smart and complex modules that earlier I could only dream about;) And the really strange is that these complex modules start working in a reasonably short time.

A release is coming

OpenERP 5.0 seems to be very close. This week only bugfixes and minor improvements were committed in trunk.

Books and other useful documentation

Visit the OpenObject Documentation site, there you can find the OpenERP books and other valuable documentation. The OpenERP Book on the main page is the book that we could buy in the webshop extended with two chapters, stock and production management. The whole site is in development, changing rapidly but for us who needed this information yesterday it's already a good solution. The whole thing can be downloaded from a launchpad site. The source is in rst format and Sphinx >0.5 can generate html, latex and pdf from it.

Debugging and profiling

There are two recently added tools that can help OpenObject developers, debug() and @profile.
If you insert debug(variable) somewhere in your code it prints the variable name and contents to the server console. To use it, you have to 'from tools.misc import debug' and start the server with '--log-level=debug'.
Profiling measures method and function execution times. Look it up in the Python Standard Library. 'profile' should be used as a function/method decorator but unfortunately I don't know how to make it work yet...

New field: type_tax_use in account

Account.tax.type_tax_use has been recently added to trunk. It is a selection field that can have a purchase, sale or all value and it is used as a domain in purchase and sale views to filter the right kind of taxes.
So from now on purchase forms only purchase taxes and on sale forms only sales taxes can be selected. 'All' type taxes appear in all places (this was the old behaviour).

Unicode reports with ReportLab

Yesterday I've just figured out that OpenERP's default report engine is still unable to create PDF reports with full unicode character support. Only the characters present in the Latin1 encoding are allowed.
This is all because the PDFs are genereated with the old standard Type1 fonts that have only Latin1 characters. The solution is to use TrueType fonts that have proper unicode support.
After browsing the forums and the net for some time I created a blueprint and a wikipage with a possible solution.
bug: https://bugs.launchpad.net/bugs/319595