Asynchronous Messaging with OpenERP

We already have synchronous messaging with XML-RPC. Now a new module is created that provides a framework to make async messaging easy with OpenERP.

The module should be used for building integration solutions based on messaging patterns.
It provides:
- A framework for sending and receiving STOMP messages.
- A serializator/deserializator that creates and reads an XML representation of any OpenERP object.
The module is based on Cloves J. G. de Almeida's mbi module, especially the XML serializator.

There's also a demo module that has a pre-built interface to sending and receiving messages.

I've put the modules async_messaging and async_messaging_demo in stable 5.0 extra addons.

Great improvements in label printing

Based on the work of Zikzakmedia, I extended the label printing capabilities of OpenERP. My goal was to provide quick high-volume product label printing.

The following improvements were made:
-Better usability like label language selection and default label format for every template.
-Refactoring to make it possible to easily add printing engines.
-Added a mako-RML engine to the existing mako-XSL:RML engine that has more possibilities in label design and eliminates an extra step that could be source of errors.
-Added a mako-SLCS engine to print to Bixolon label printers.
-Added an editable grid to fill in with products and label quantities to print plus a button on pickings to automatically fill in this grid from their data.

The modules that provide these functionalities:
-label: made by Zikzakmedia in stable 5.0 extra addons. Provides PDF printing with XSL:RML and RML.
-label_product in stable 5.0 extra addons
-label_slcs in stable 5.0 extra addons
-For label_slcs it is useful to install the printjob module from community addons that could send the generated commands directly to the printer. It's made by Pegueroles SCP & NaN.

base_report_unicode v1.2

The base_report_unicode module has been updated to support <b>, <i> (bold and italic) tags. OpenERP by default ignores those if used with TrueType fonts.
The DejaVu fonts are also updated to the latest versions.

Restrict access to moves, pickings and locations

I've just published a new module in community addons

This module allows filtering of pickings and stock inventories by location. It's useful to restrict stock workers to only see those pickings that are relevant to them.

Technically: pickings get their unused location_id, location_dest_id fields redefined to be filled in from their moves' data. Inventories get a location_ids field from their lines' data.

Product related price list items

I've just published a new module called product_related_pricelis_items in stable 5.0 extra addons

A convenience wizard on the product form to show and edit only the price list items that are relevant. This means that you can choose a price list version from the product form and you get an editable grid with only those items that are defined for that product or it's categories (including some parents) or aren't restricted at all.

NOTE: Needs the --enable-code-actions parameter for the server.

Customer credit limit control module

I've just published a new module in stable 5.0 extra addons

The Sale Order confirming button checks if the partner's
receivables minus payables plus the order's total
exceeds her credit limit.
If it does, it doesn't let the user to confirm the order.
Managers have an extra button to bypass the check but
of course the credit limit itself could be lifted, too.

System backup tool for OpenERP

I've just published a new module in community addons

This is a system backup tool that can be run from the OpenERP
user interface. It is meant for system administrators.
It doesn't do the backup itself but provides a convenient
framework to run python backup scripts. There are several
example scripts provided that can be run outside OpenERP
so they can be easily tested.
Backup scripts are called Tasks and they don't do device
mounting and unmounting but that's provided by the scripts
in the object Target.
The result of a backup operation is called a Job. There are
tar and rsync kind of jobs supported.

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:)