How to install OpenERP 6.0 on Ubuntu 10.04 LTS Server (Part 2 – SSL)

This article follows on (hopefully not unsurprisingly) from part 1.

In this post I’ll describe our current way of providing SSL encrypted access to a shiny new OpenERP server running on Ubuntu 10.04 LTS Server.

We’re using the Apache webserver to act as a proxy and do SSL termination for web client access and for WebDAV/CalDAV access. The GTK client will also be running over an encrypted XMLRPC link directly to the OpenERP Server. Apache is the most widely used webserver in the world and there is oodles of documentation about it so I do not plan to go into any great detail about the configuration choices. One document that is worth pointing out however is the information about how to configure and administer Apache specifically under Debian/Ubuntu. The way Apache is packaged and set up is quite different from most other Linux distributions. A very useful document can be found here /usr/share/doc/apache2.2-common/README.Debian.gz on your server.

NB: For the purposes of this how to, we’ll be using self-signed certificates. A discussion of the pros and cons of this choice is beyond the scope of this article.

Step 1. Install Apache and required modules

On your server install apache2 by typing

sudo apt-get install apache2

Now we’ll tell apache that we want to use a few modules (mod_ssl, mod_proxy, mod_proxy_http, mod_headers and mod_rewrite [optional]) that are not enabled by default:

sudo a2enmod ssl proxy_http headers rewrite

Next, we need to generate a SSL certificate and key.

Step 2. Create your cert and key

I create the files in a temporary directory then move them to their final resting place once they have been built (the first cd is just to make sure we are in our home directory to start with):


cd
mkdir temp
cd temp

Then we generate a new key, you will be asked to enter a passphrase and confirm:

openssl genrsa -des3 -out server.pkey 1024

We don’t really want to have to enter a passphrase every time the server starts up so we remove the passphrase by doing this:

openssl rsa -in server.pkey -out server.key

Next we need to create a signing request which will hold the data that will be visible in your final certificate:

openssl req -new -key server.key -out server.csr

This will generate a series of prompts like this: Enter the information as requested:

You are about to be asked to enter information that will be incorporated into your certificate request. What you are about to enter is what is called a Distinguished Name or a DN. There are quite a few fields but you can leave some blank For some fields there will be a default value, If you enter ‘.’, the field will be left blank.
—–
Country Name (2 letter code) [AU]:
State or Province Name (full name) [Some-State]:
Locality Name (eg, city) []:
Organization Name (eg, company) [Internet Widgits Pty Ltd]:
Organizational Unit Name (eg, section) []:
Common Name (eg, YOUR name) []:
Email Address []:

Please enter the following ‘extra’ attributes
to be sent with your certificate request
A challenge password []:
An optional company name []:The Client’s Company

And finally we self-sign our certificate.

openssl x509 -req -days 365 -in server.csr -signkey server.key -out server.crt

We only need two of the files in the working directory, the key and the certificate. But before we can use them they need to have their ownership and access rights altered:


sudo chown openerp:root server.crt server.key
sudo chmod 640 server.crt server.key

And then we put them in a sensible place:


sudo mkdir /etc/ssl/openerp
sudo chown openerp:root /etc/ssl/openerp
sudo chmod 710 /etc/ssl/openerp
sudo mv server.crt server.key /etc/ssl/openerp/

Now the key and certificate are safely stored away, we can tell Apache where they are:

Step 3. Create the Apache site configuration file

We create a new Virtual Host configuration file

sudo nano /etc/apache2/sites-available/openerp-ssl

with the following content:


SSLEngine on
SSLCertificateFile /etc/ssl/openerp/server.crt
SSLCertificateKeyFile /etc/ssl/openerp/server.key

ProxyRequests Off


Order deny,allow
Allow from all

ProxyVia On

ProxyPass /webdav/ http://127.0.0.1:8069/webdav/

ProxyPassReverse /webdav/

Order Deny,Allow
Allow from all
Satisfy Any

ProxyPass / http://127.0.0.1:8080/

ProxyPassReverse /

RequestHeader set "X-Forwarded-Proto" "https"

# Fix IE problem (httpapache proxy dav error 408/409)
SetEnv proxy-nokeepalive 1

Note there are two Proxy configurations. One for /webdav/ and one for /. If you do not intend to use WebDAV or CalDAV then you can remove that section. But essentially, we are telling apache that WebDAV traffic needs to go to the XMLRPC port on the OpenERP server, and normal web traffic needs to go to the web client that is listening on port 8080. The order is also important. If / came before /webdav/ then it wouldn’t work.

And then we can enable the new site configuration.

sudo a2ensite openerp-ssl

Optionally, you can use mod_rewrite to redirect any normal (non-encrypted) web browser traffic to the SSL port (443).

To do this, add the following lines (outside of the config blocks) into the file /etc/apache2/sites-available/default

RewriteEngine on
RewriteCond %{SERVER_PORT} ^80$
RewriteRule ^(.*)$ https://%{SERVER_NAME}$1 [L,R]

Step 4. Change the OpenERP server and web-client configuration files

The next step is to re-configure the OpenERP server and Web client so that the non-encrypted services are not accessible from the outside world.

In /etc/openerp-server.conf the two non-encrypted services will only listen on localhost, i.e. not from external connections so in effect only traffic from Apache will be accepted. We also tell the XMLRPC-SSL service where to find the necessary key and certificate.

Make the following changes:

sudo nano /etc/openerp-server.conf

xmlrpc = True
xmlrpc_interface = 127.0.0.1
xmlrpc_port = 8069

netrpc = True
netrpc_interface = 127.0.0.1
netrpc_port = 8070

xmlrpcs = True
xmlrpcs_interface =
xmlrpcs_port = 8071
secure_pkey_file = /etc/ssl/openerp/server.key
secure_cert_file = /etc/ssl/openerp/server.crt

If you want to have WebDAV/CalDAV access add the following at the bottom of the config file.

[webdav]
enable = True
vdir = webdav

Then in the web client config file /etc/openerp-web.conf make the following changes so that it also only accepts traffic from localhost:

sudo nano /etc/openerp-web.conf

# Some server parameters that you may want to tweak
server.socket_host = “127.0.0.1”

# Set to True if you are deploying your App behind a proxy
# e.g. Apache using mod_proxy
tools.proxy.on = True

# If your proxy does not add the X-Forwarded-Host header, set
# the following to the *public* host url.
tools.proxy.base = ‘https://your-ip-or-domain’

# Set to false to disable CSRF checks
tools.csrf.on = False

That’s it.

Step 5. Try it out

Restart the services to load the new configurations


sudo service openerp-server restart
sudo service openerp-web restart
sudo service apache2 restart

You should not be able to connect to the web client on port 8080 and the GTK client should not connect on either the NetRPC (8070) or XMLRPC (8069) services. For the web access you just need to visit https://your-ip-or-domain and in the GTK client you will need to use port 8071 and choose the XMLRPC (Secure) protocol.

For CalDAV access the URL to a calendar will be something like this:

https://your-ip-or-domain/webdav/DB_NAME/calendars/users/USERNAME/c/CALENDAR_NAME

I hope that is helpful and obviously we’d love to hear comments and suggestions for improvements.

April 21st, 2011 | Alan Lord | Tags: , , , , .
Categories: FLOSS in the news, OpenERP, Ubuntu | Comments: 78 Comments

How to install OpenERP 6.0 on Ubuntu 10.04 LTS Server (Part 1)

Update: 22/02/2012. OpenERP 6.1 was released today. I’ve written a howto for this new version here.

OpenERP LogoRecently at work, we’ve been setting up several new instances of OpenERP for customers. Our server operating system of choice is Ubuntu 10.04 LTS.

Installing OpenERP isn’t really that hard, but having seen several other “How Tos” on-line describing various methods where none seemed to do the whole thing in what I consider to be “the right way”, I thought I’d explain how we do it. There are a few forum posts that I’ve come across where the advice is just plain wrong too, so do be careful.

As we tend to host OpenERP on servers that are connected to the big wide Internet, our objective is to end up with a system that is:

      A: Accessible only via encrypted (SSL) services from the GTK client, Web browser, WebDAV and CalDAV
      B: Readily upgradeable and customisable

One of my friends said to me recently, “surely it’s just sudo apt-get install openerp-server isn’t it?” Fair enough; this would actually work. But there are several problems I have with using a packaged implementation in this instance:

  • Out-of-date. The latest packaged version I could see, in either the Ubuntu or Debian repositories, was 5.0.15. OpenERP is now at 6.0.3 and is a major upgrade from the 5.x series.
  • Lack of control. Being a business application, with many configuration choices, it can be harder to tweak your way when the packager determined that one particular way was the “true path”.
  • Upgrades and patches. Knowing how, where and why your OpenERP instance is installed the way it is, means you can decide when and how to update it and patch it, or add custom modifications.

So although the way I’m installing OpenERP below is manual, it gives us a much more fine-grained level of control. Without further ado then here is my way as it stands currently (“currently” because you can almost always improve things. HINT: suggestions for improvement gratefully accepted).

[Update 18/08/2011: I’ve updated this post for the new 6.0.3 release of OpenERP]

Step 1. Build your server

I install just the bare minimum from the install routine (you can install the openssh-server during the install procedure or install subsequently depending on your preference).

After the server has restarted for the first time I install the openssh-server package (so we can connect to it remotely) and denyhosts to add a degree of brute-force attack protection. There are other protection applications available: I’m not saying this one is the best, but it’s one that works and is easy to configure and manage. If you don’t already, it’s also worth looking at setting up key-based ssh access, rather than relying on passwords. This can also help to limit the potential of brute-force attacks. [NB: This isn’t a How To on securing your server…]

sudo apt-get install openssh-server denyhosts

Now make sure you are running all the latest patches by doing an update:

sudo apt-get update
sudo apt-get dist-upgrade

Although not always essential it’s probably a good idea to reboot your server now and make sure it all comes back up and you can still login via ssh.

Now we’re ready to start the OpenERP install.

Step 2. Create the OpenERP user that will own and run the application

sudo adduser --system --home=/opt/openerp --group openerp

This is a “system” user. It is there to own and run the application, it isn’t supposed to be a person type user with a login etc. In Ubuntu, a system user gets a UID below 1000, has no shell (well it’s actually /bin/false) and has logins disabled. Note that I’ve specified a “home” of /opt/openerp, this is where the OpenERP server, and optional web client, code will reside and is created automatically by the command above. The location of the server code is your choice of course, but be aware that some of the instructions and configuration files below may need to be altered if you decide to install to a different location.

Step 3. Install and configure the database server, PostgreSQL

sudo apt-get install postgresql

Then configure the OpenERP user on postgres:

First change to the postgres user so we have the necessary privileges to configure the database.

sudo su - postgres

Now create a new database user. This is so OpenERP has access rights to connect to PostgreSQL and to create and drop databases. Remember what your choice of password is here; you will need it later on:


createuser --createdb --username postgres --no-createrole --no-superuser --pwprompt openerp
Enter password for new role: ********
Enter it again: ********

[Update 18/08/2011: I have added the --no-superuser switch. There is no need for the openerp database user to have superuser privileges.]

Finally exit from the postgres user account:

exit

Step 4. Install the necessary Python libraries for the server


sudo apt-get install python python-psycopg2 python-reportlab \
python-egenix-mxdatetime python-tz python-pychart python-mako \
python-pydot python-lxml python-vobject python-yaml python-dateutil \
python-pychart python-webdav

And if you plan to use the Web client install the following:


sudo apt-get install python-cherrypy3 python-formencode python-pybabel \
python-simplejson python-pyparsing

Step 5. Install the OpenERP server, and optional web client, code

I tend to use wget for this sort of thing and I download the files to my home directory.

Make sure you get the latest version of the application files. At the time of writing this it’s 6.0.2 6.0.3; I got the download links from their download page.


wget http://www.openerp.com/download/stable/source/openerp-server-6.0.3.tar.gz

And if you want the web client:


wget http://www.openerp.com/download/stable/source/openerp-web-6.0.3.tar.gz

Now install the code where we need it: cd to the /opt/openerp/ directory and extract the tarball(s) there.


cd /opt/openerp
sudo tar xvf ~/openerp-server-6.0.3.tar.gz
sudo tar xvf ~/openerp-web-6.0.3.tar.gz

Next we need to change the ownership of all the the files to the openerp user and group.


sudo chown -R openerp: *

And finally, the way I have done this is to copy the server and web client directories to something with a simpler name so that the configuration files and boot scripts don’t need constant editing (I call them, rather unimaginatively, server and web). I started out using a symlink solution, but I found that when it comes to upgrading, it seems to make more sense to me to just keep a copy of the files in place and then overwrite them with the new code. This way you keep any custom or user-installed modules and reports etc. all in the right place.


sudo cp -a openerp-server-6.0.3 server
sudo cp -a openerp-web-6.0.3 web

As an example, should OpenERP 6.0.4 come out next, I can extract the tarballs into /opt/openerp/ as above. I can do any testing I need, then repeat the copy command (replacing 6.0.3 obviously) so that the modified files will overwrite as needed and any custom modules, report templates and such will be retained. Once satisfied the upgrade is stable, the older 6.0.3 directories can be removed if wanted.

That’s the OpenERP server and web client software installed. The last steps to a working system are to set up the two (server and web client) configuration files and associated init scripts so it all starts and stops automatically when the server boots and shuts down.

Step 6. Configuring the OpenERP application

The default configuration file for the server (in /opt/openerp/server/doc/) could really do with laying out a little better and a few more comments in my opinion. I’ve started to tidy up this config file a bit and here is a link to the one I’m using at the moment (with the obvious bits changed). You need to copy or paste the contents of this file into /etc/ and call the file openerp-server.conf. Then you should secure it by changing ownership and access as follows:


sudo chown openerp:root /etc/openerp-server.conf
sudo chmod 640 /etc/openerp-server.conf

The above commands make the file owned and writeable only by the openerp user and only readable by openerp and root.

To allow the OpenERP server to run initially, you should only need to change one line in this file. Toward to the top of the file change the line db_password = ******** to have the same password you used way back in step 3. Use your favourite text editor here. I tend to use nano, e.g. sudo nano /etc/openerp-server.conf

Once the config file is edited, you can start the server if you like just to check if it actually runs.

/opt/openerp/server/bin/openerp-server.py --config=/etc/openerp-server.conf

It won’t really work just yet as it isn’t running as the openerp user. It’s running as your normal user so it won’t be able to talk to the PostgreSQL database. Just type CTL+C to stop the server.

Step 7. Installing the boot script

For the final step we need to install a script which will be used to start-up and shut down the server automatically and also run the application as the correct user. Here’s a link to the one I’m using currently.

Similar to the config file, you need to either copy it or paste the contents of this script to a file in /etc/init.d/ and call it openerp-server. Once it is in the right place you will need to make it executable and owned by root:


sudo chmod 755 /etc/init.d/openerp-server
sudo chown root: /etc/init.d/openerp-server

In the config file there’s an entry for the server’s log file. We need to create that directory first so that the server has somewhere to log to and also we must make it writeable by the openerp user:


sudo mkdir /var/log/openerp
sudo chown openerp:root /var/log/openerp

Step 8. Testing the server

To start the OpenERP server type:

sudo /etc/init.d/openerp-server start

You should now be able to view the logfile and see that the server has started.

less /var/log/openerp/openerp-server.log

If there are any problems starting the server now you need to go back and check. There’s really no point ploughing on if the server doesn’t start…

OpenERP - First Login

OpenERP - First Login

If you now start up the GTK client and point it at your new server you should see a message like this:

Which is a good thing. It means the server is accepting connections and you do not have a database configured yet. I will leave configuring and setting up OpenERP as an exercise for the reader. This is a how to for installing the server. Not a how to on using and configuring OpenERP itself…

What I do recommend you do at this point is to change the super admin password to something nice and strong. By default it is “admin” and with that a user can create, backup, restore and drop databases (in the GTK client, go to the file menu and choose the Databases -> Administrator Password option to change it). This password is written as plain text into the /etc/openerp-server.conf file. Hence why we restricted access to just openerp and root.

One rather strange thing I’ve just realised is that when you change the super admin password and save it, OpenERP completely re-writes the config file. It removes all comments and scatters the configuration entries randomly throughout the file. I’m not sure as of now if this is by design or not.

Now it’s time to make sure the server stops properly too:

sudo /etc/init.d/openerp-server stop

Check the logfile again to make sure it has stopped and/or look at your server’s process list.

Step 9. Automating OpenERP startup and shutdown

If everything above seems to be working OK, the final step is make the script start and stop automatically with the Ubuntu Server. To do this type:

sudo update-rc.d openerp-server defaults

You can now try rebooting you server if you like. OpenERP should be running by the time you log back in.

If you type ps aux | grep openerp you should see a line similar to this:

openerp 708 3.8 5.8 181716 29668 ? Sl 21:05 0:00 python /opt/openerp/server/bin/openerp-server.py -c /etc/openerp-server.conf

Which shows that the server is running. And of course you can check the logfile or use the GTK client too.

Step 10. Configure and automate the Web Client

Although it’s called the web client, it’s really another server-type application which [ahem] serves OpenERP to users via a web browser instead of the GTK desktop client.

If you want to use the web client too, it’s basically just a repeat of steps 6, 7, 8 and 9.

The default configuration file for the web client (can also be found in /opt/openerp/web/doc/openerp-web.cfg) is laid out more nicely than the server one and should work as is when both the server and web client are installed on the same machine as we are doing here. I have changed one line to turn on error logging and point the file at our /var/log/openerp/ directory. For our installation, the file should reside in /etc/, be called openerp-web.conf and have it’s owner and access rights set as with the server configuration file:


sudo chown openerp:root /etc/openerp-web.conf
sudo chmod 640 /etc/openerp-web.conf

Here is a web client boot script. This needs to go into /etc/init.d/, be called openerp-web and be owned by root and executable.


sudo chmod 755 /etc/init.d/openerp-web
sudo chown root: /etc/init.d/openerp-web

You should now be able to start the web server by entering the following command:

sudo /etc/init.d/openerp-web start

Check the web client is running by looking in the log file, looking at the process log and, of course, connecting to your OpenERP server with a web browser. The web client by default runs on port 8080 so the URL to use is something like this: http://my-ip-or-domain:8080

Make sure the web client stops properly:

sudo /etc/init.d/openerp-web stop

And then configure it to start and stop automatically.

sudo update-rc.d openerp-web defaults

You should now be able to reboot your server and have the OpenERP server and web client start and stop automatically.

I think that will do for this post. It’s long enough as it is!

I’ll do a part 2 in a little while where I’ll cover using apache, ssl and mod_proxy to provide encrypted access to all services.

[UPDATE: Part 2 is here]

April 19th, 2011 | Alan Lord | Tags: , , , , , , , , , .
Categories: OpenERP, The Open Learning Centre, Ubuntu | Comments: 183 Comments

OpenERP vs Lotus Domino

I spent last week out in Belgium, the home of fine chocolates, waffles and Open Source Enterprise Resource Planning applications. I was lucky enough to sample all three as I was on a training course in the OpenERP head office. OpenERP 6 has just been released and it is an amazing thing to have a full ERP system that is Free Software and has Ubuntu as the preferred platform (we were all given an Ubuntu VMware/Virtualbox virtual machine for the training course). The training I did covered the technical aspects of the OpenObject framework rather than the accountancy and business management angle of the functional training, in fact throughout the course we did nothing related to moving money and stock about.
Back in the past I used to be a Lotus Notes and Domino developer, building business applications for medium to large enterprises all over the world. Notes has a bit of a reputation for being unpopular with users for a variety of reasons, but if you forget about the email client aspects of it the underlying platform is the granddaddy of all the NoSQL database engines and a forms based development environment which, despite IBM’s best efforts to break it, is still rather powerful. The OpenObject platform is similarly powerful, it has a few advantages and a few drawbacks, what I want to do here is provide a bit of a comparison and terminology cross reference between the two platforms and see what concepts are common to both. I will be referring throughout to OpenObject rather than OpenERP because I am talking about the framework on which OpenERP is written, just like Notes Mail is an application on the Notes framework.

Database / Server

The OpenERP server can host multiple databases, each one contains totally isolated set of applications and a different set of user profiles, I think of this like multiple Name and Address books and as each openERP database effectively has a separate NAB I would compare them to separate servers or perhaps domains in the Notes world.

Modules / Databases

Yeah, I know databases sort of got renamed to Applications in the Notes client but everyone still calls them databases. In OpenObject this maps most closely to a Module. A database is a collection of related stuff that comes together to peform some useful function. A bunch of modules might work together to form an integrated suite, just like a suite of databases in Notes or the OpenERP suite of modules.

Model and Form View / Form

In OpenObject you list the fields an object has in a python class. This is the back end list of fields that corresponds to the fields on a Notes form. There is a separate file in XML format where the layout of the form is defined. There is a slightly confusing terminology clash here, in OpenObject this is called a form view. If you don’t define a form view it will create an automatic one for you just laying out all the fields defined on your model with their labels in a 4 column grid. So in summary forms in OpenObject are done in two parts, back end field definitions in python and front end layout in XML.

_defaults / Field default values

default values can be pre-filled in new documents by creating a _defaults dictionary in your model class. Basically this is a list of the back end fields that you want to give a starting value to and the value you want.

_constraints and _sql_constraints / Validation formulas

The _constraints dictionary is a set of rules that are enforced just in the user interface, these are implemented as python functions that get passed the relevant field values and return true or false and if neccessary give a message to the user on what is required. _sql_constraints are written down to the database layer so will be enforced even if the document is edited programatically without using the forms user interface.

Records / Documents

OpenObject uses PostgreSQL engine as the underlying database engine, this is a big grown up RDBMS, more comparable to Oracle than the fast and lightweight MySQL. The back end of a document in OpenObject is a record in a table. These are abstracted a bit by the ORM (Object Relational Mapper) so you don’t need to worry too much about the underlying tables, text fields can have up to 1GB of text in them and you can do multivalue fields (called selection fields) and have relational fields that you can think of like an array of doclinks but actually they add columns to tables or create new tables to allow joins and things to happen in the SQL layer as appropriate. You don’t need to worry about this bit too much, it just works. Changes work too. If you add a new field to your model you can just start using it, when the server starts and updates your module it will adjust the schema without losing data to accomodate your new field. If the new field is mandatory then you must provide a default value so it can backfill the existing documents, but if not you can just add the field and start using it like in Notes.

Functional fields / Computed and Computed for display fields

Functional fields can be set to store the value to the database or not.

Read only fields / Computed when composed fields

If a field has a default value and is read only then it will act like a computed when composed field in Notes.

Tree Views / Views

So in OpenObject the UI of a document is called the “form view”, when looking at a bunch of documents this is known in the user interface as “list mode” but in the back end it is actually a “tree view” which you might correctly surmise means it can correspond to a categorised view in Notes. There have been some optimisations in version 6 which allow progressive loading of collapsed tree views which allows the client to drill down into a huge view without loading all the rows, a bit like Notes does. Unlike Notes I don’t think it does progressive loading of flat views, so you probably have to be a bit careful of lists with many thousands of rows as it will send all of the data to the client on opening the view.

Calendar Views / Calendar Views

These really correspond rather well from the OpenObject concept to the same thing in Notes, it is just a treeview but you specify the column that is your start time and which one is your duration. Time zone support is a tricky subject in both, but there is no real perfect solution for all situations when it comes to timezones.

Gantt views / n/a

I never really figured out why Notes didn’t grow a nice gantt chart view format, it would have been so easy to do, probably simpler than the calendar view. OpenObject has one and it works fine, similar to the calendar it is just a tree view and you tell it which column is the start, duration and which contains links that draw dependency lines to other documents. Simples.

Diagram Views / n/a

These allow you to map out related objects, I think it was implemented to allow a visual workflow editor to be built but I could see how you would use this to have a dynamically drawn org chart in an HR application for example.

Graph Views / n/a

Graphing data is great and this works in both the GTK desktop client and in the web client with a rather fancy looking Flash graphing object. Again, these are simple to make, just views with a few extra rules to tell it to draw a bar chart or pie chart and whether to group by a particular value and what operator to use when grouping, this allows you to have bar charts that sum values from related documents. This isn’t supposed to be a sophisticated graphing toolkit, just a nice easy way to visualise some of the data in the ERP system.

Domain / Selection formula

Domains in OpenObject are expressed in a rather odd python syntax as a list of tuples and conditions half in reverse polish notation and half in the normal order. They can be used to restrict the number of options in a dropdown list (e.g. a dropdown list of states that shows the right options based on what you choose in the country field) and can also be used to restrict what’s displayed in tree views just like a view selection formula.

Python / Lotusscript

OK so I am going to be a language snob for a bit here. Lotusscript is nice and easy, it is a dialect of BASIC and does allow a reasonable amount of modern object oriented coding, but it just isn’t an actively developed language and nobody wants to be a BASIC programmer. IBM understand this and have been trying for years to get Java to do half the stuff you can do with Lotusscript but without credible front-end integration in Java it just isn’t going to happen. Python is a proper modern language that has an active development community around it. It is as easy to use as Lotusscript, it lacks all the syntactical punctuation of Java and C++ and there is none of the indignity of having to do your own pointer arithmetic like you get with C. There are Python libraries to do pretty much anything you could possibly imagine, there is no great app store of .lsx files waiting to be called in to extend your Lotusscript capabilities.

Access Controls List / Access Control Lists

All the modules installed on your server add options to the central consolidated Access Controls List rather than each application having a separate ACL. Access can be given to groups of users at the record type or object level and you can give read/write/create/delete access. This is kind of like setting the access rules on forms in Notes (the key tab on the form properties that nobody uses because readername fields on a form make bad things happen). For more fine control there are Record Rules, this is where you would implement Author and reader field type security to allow an Employee to see HR records where the EmployeeID is equal to the current user ID for example.

n/a / Replication

This doesn’t really exist in the OpenObject world. It is a client-server model and if you want to do anything you need access to the server. You can have multiple servers in a high availability cluster but there is no multi-server replication. There is support for using the server over XMLRPC which allows a dumb client (i.e. with no locally installed code other than python) to access the full OpenObject API including methods defined in your custom modules. This could be used to write a simple offline client that can then synchronise objects with the OpenERP server. You could even write an interface to synchronise data to a Notes client. Hmm, I might actually do that at some point.

n/a / What You See Is What You Get

Notes is a WYSIWYG development environment. If you want a field label green or change a table border width you just make it so because you are simply editing a block of rich text. This makes form development in Notes falling-off-a-log easy. It also gives you the flexibility to make a right old mess on screen. OpenObject is more declarative, which leads to less addition of random bling and more consistency across the entire database, which is what you want really. A corporate theme (which I haven’t figured out how to do yet) would apply to all modules in the database regardless of where they came from.

n/a / Public Key Authentication

This is just baked in to the Notes API at a really low level and simply isn’t there in OpenERP. Yes, administering ID files can be a pain in Notes and users tend not to want to invest any time in understanding the value of them over a username and password, but having real encryption and signatures as a fundamental feature is awesome, even if they are woefully missunderstood by the development community and undervalued by the users.
One interesting and somewhat related feature on the roadmap is that OpenERP is going to grow OpenID authentication, thus it will allow you to log on to OpenERP using credentials from Google, Facebook, Launchpad accounts etc.

Internationalisation / Domino Global Workbench

OpenObject uses a common internationalisation framework used in Open Source projects based on the GNU gettext format, all modules are written in US English then all the strings are exported to a .pot template files and .po files are created with translated strings for each target language. The Launchpad website has a great collaborative interface for allowing anyone to contribute and validate translations of your modules. I have done multi-lingual notes databases and yes, there was an attempt to integrate translations into Notes in Domino Global Workbench, last time I looked at that it was a bit rubbish.

Workflow / Lotus Workflow,formally known as Domino.Workflow

The graphical workflow engine is an optional extra on the Notes side (and a pig to integrate – yes I have done it) but built in as a standard feature across all modules in OpenERP. It has a nice graphical editor and you can do quite powerful operations and state transitions on multiple objects and call sub-workflows and so on. It does take a bit of getting used to, but it is the same across all modules.

Reporting and Printing / n/a

Actually I always had stuff printing out OKish from Notes, but OpenERP has a proper reporting engine built in based on the RML Report Markup Language It allows you to create fancy looking reports combining data from multiple objects plus images, barcodes and other complicated things.

Text & HTML / Rich Text

Well there is no native concept of rich text in OpenObject, there are text fields which can be big and can contain HTML and in the web client you can shoehorn in a web HTML editor. Basically it doesn’t compare to Notes if you want formatted text as a native datatype. That said, Notes Rich Text is a major pain when it gets down to doing stuff with it at CD record level or hacking about with rich text stored as MIME, or even using the NotesRichTextNavigator object to work with it. Rich text in OpenObject is limited, but that isn’t as much of an issue as you might expect and when you do integrate formatted objects things will at least be standards compliant and you will be manipulating HTML or perhaps ODF or possibly even MediaWiki markup – there is a wiki module but I can’t get it to render the pages – tips on this in the comments please if you know how.

AGPL / Proprietary

The OpenObject framework is licensed under the Affero GPL. This means that to comply with the license all your modules should be AGPL or a compatible license. If your business model relies on restricting the freedom of your customers you can look away now. Personally I always encouraged customers of Notes development work to review and look at my code and share and reuse it, plus I published interesting things developed or discovered for discussion with other developers in the community. I know this isn’t universal and some people do get all protective about intellectual property rights and like to hide their source code. There is actually no conflict at all between meeting the requirements of the GPL and being paid by a customer to build something they want. As long as you can get past this mental hurdle it really makes little difference to a bespoke software development business.

In Conclusion

Notes is OK, but proprietary and closed and quirky and carrying over 20 years of baggage with it. OpenERP has more of a rigorous and correct feel to it with standards compliance, a modern framework, nice APIs and a real grown up relational back end with transactions and atomicity and so on. The NoSQL engine at the core of Notes is a great idea, and new implementations of the architecture such as CouchDB are dead handy, especially for distributed applications.

All these detail comparisons are rather academic, the bottom line is that having poked about at the application development layer of OpenObject and looking back at all the Notes applications I have written over the last 15 years or so I am left thinking that most of them I could rebuild now in OpenObject, but slightly better.

One final note, I am going to delete uninformed and outdated Notes bashing in the comments, if you were going to say something like “I once used Notes 5 in a place I worked and everyone hated using it for email” then please save the wear on your keyboard and don’t bother, but if you have some clueful and current bashing you want to get off your chest (of either Notes or OpenERP) then pitch right in.
January 23rd, 2011 | Alan Bell | Categories: OpenERP, The Open Learning Centre, Ubuntu | Comments: 14 Comments

« Previous Page