Import ODBC module steps up

The import_odbc module for OpenERP was recently improved and moved  to the OpenObject Extension community project. the original module is now split in two: base_external_dbsource and import_odbc.

The import_odbc code was refactored, but keeps the same funcionality as before. Documentation was improved and some examples are provided out of the box.

The base_external_dbsource was created to isolate the logic for connecting to external databases and executing SQL queries. It's used by import_odbc, but it also enables other modules to fetch foreign data on the fly.

Additionally, the connection types supported were extended. Support for ODBC and Oracle native connections is kept, and support for other native connections was added:

• MS SQL Server
• MySQL
• PostgreSQL
• SQLite

With this evolution, it would be more fair to name the module as "import_sql" instead of the "import_odbc", but the name was kept unchanged to avoid confusing current users.

You can get the latest version of these modules from the OpenObject Extension trunk branch:

bzr branch lp:openobject-extension

Share you experiences and feature wishlists with us!

Using codes to search and enter data in OpenERP forms

Using codes to refer to entities, such as customers or employees, is a common practice, and widely used in ERPs. To users familiar with this method it's natural to have the code displayed alongside with the description, and to enter data in a form field by directly typing a code.

This feature can be easilly added to OpenERP using the refcodes family of modules, available in Launchpad. For example, in the HR module an employee selection list might look like this:

Have fun.

Trigger-like Automated Actions

OpenERP's Automated Actions is a module usually associated with the CRM modules, allowing to automate sales process steps, without the need to write Python code.

Each automated action rule operates on an OpenERP model, any model. It's  behaviour is defined through three tabs:

• Conditions tell when the rule is fired.
• Actions tell what operations should be done, like setting a specific user as Responsible person, or running a Server Action.
• E-mail actions allows to define e-mail messages to be sent .

Conditions can be activated at scheduled moments. This is the sole purpose of the "Conditions on Time" section. The scheduler action evaluates these conditions to decide what rules to trigger. This allows you to configure actions like "send an e-mail reminder two days after last action date".


The remaining conditions are evaluated immediately when a record is saved. This allows you to configure actions like "send an e-mail when state is changed to In Progress".


While you get the feeling of having a lot of potential to easily customize a customer's very specific business rules, actually the module reveals to fall short on the expectations.
For instance, it's not possible to create conditions for:

• When a new Issue is created, sending an e-mail informing the new Issue;
• When the Responsible is changed, sending an e-mail informing the new responsible person.

Also, the e-mail actions definition is very confusing and limited. The e-mail Subject line is not configurable, and the message body can only use a small list of keyword to include data from the document.

The reis_base_action_rule_triggers module overcomes these limitations and unlocks a lot of the power of the standard module. This is done through two simple additions:

• Conditions can be defined by an "Evaluated expression", that can work on record's old and new values.
• Actions can send an e-mail using v6.1 Email templates, a lot more powerful than the "e-mail actions" options, making them obsolete.

In the condition expressions some variables are available (inspiration came from Oracle's database triggers):

• inserting, creating: boolean indicating it's a new record is being created;
• updating, writing: boolean indicating it's an existing record being changed;
• new: a dictionary with all the values after the record is changed;
• old: a dictionary with all the values before the record was changed;
• changed: a dictionary with only the values that actually changed, even if rewritten (empty if not updating);
• obj: browseable record object, allowing dot notation, with the new/changed record.

Here are some real examples used in a production environment for the Project Issue module:


New issue is created, or is reactivated:
inserting or changed.get('state') == 'draft'


Issue is closed or cancelled:
changed.get('state') in ('done', 'cancel')


Issue's Responsible changed:
old.get('user_id') and new.get('user_id')
and old.get('user_id') != new.get('user_id') 
and not new.get('date_open')  #date_open is written only by Open issue

I hope this turn out useful to more people, and would love to hear about your experience with this module.

How to: allow Project Users to record Time on Tasks for anyone

If you have hr_timesheet installed, users also in the Employee group will only be able to record time on tasks for themselves. If you need Project Users or Managers to be able to record time for other persons, just add the following Record Rule:

An OpenERP Apps and dependencies installer

While the apps.openerp.com site provides access to community modules, there is  no way to automatically download a module and all it's dependencies. The problem is even worse if the dependency modules are hosted in different branches.

For this, I created a tool to assist in downloading a module and all it's dependencies, in a way similar to Python's pip or Ubuntu's apt-get.

Here is a quick-start demo:

First, position your command line on your target "addons" directory. For demonstration purposes, let's use a temporary location:

mkdir /tmp/addons
cd /tmp/addons

Now install the "apps" tool and specify the OpenERP version you are working with:

bzr checkout --lightweight lp:~dreis-pt/+junk/apps
apps/init 6.1

Finally, use "apps/get" to download the modules you need. The tool will search in an index for their branch location, download and copy to the current addons directory. Let's try it with two different asterik related modules:

apps/get asterisk_click2dial asterisk360

The apps/get command depends on pre-genererated index files. The program to generate these indexes is also provided, but that's a long running operation, ment to be regularly executed by a server.

I know there are a lot of things to improve, but the current version is perfectly usable. I feel this could be an important tool for the community, so comments would be very welcome.