This weekend I've attended the Nepomuk Coding Sprint. This has resulted in Koo adding semantinc information to files users extract from OpenERP. This includes files attached to records and printed PDFs too.
What it currently does is:
- Tags: It adds the "OpenERP" tag to the file and also a tag with the name of the model, such as "Partner" or "Invoice" in user's language, of course.
- If the document has a related partner or address and the e-mail is in user's addressbook, the document is marked as related to that contact. That means you'll be able to find the file when searching for files related to that contact. No matter if you try that in dolphin, Kontact or any other application that makes use of Nepomuk.
- Tries to find a comment or note associated with the record (such as description in attachments or notes in partners) and attaches that as meta information to the file too.
- Allows rating a record in OpenERP and the rating is exported to Nepomuk on user's computer.
I've created a video so that is a bit clearer:
All this is already available in Koo in 5.0 branch if you run it under KDE and install the new 'semantic' server's module.
diumenge, 21 / juny / 2009
dissabte, 14 / febrer / 2009
Koo in POS mode
Today Koo gained a new --pos-mode which allows it to be used in touch screen environments, such as POS. Indeed, it is a proof of concept I implemented some months ago but remained untouched in a branch of my old git repository.
To run koo in pos mode simply run:
python koo.py --pos-mode --stylesheet=Pos/pos.qss
The --pos-mode flag tells koo to show a keyboard or keypad (depending on the field type) each time a text box gets the focus.
The --stylesheet flag tells koo to use the given stylesheet which mainly increases font size and padding so list items are heigher and thus easier to click with the fingers.
This gives developers the chance to use all the flexibility of OpenERP form design to POS but also allows developing touchscreen enabled interfaces for industrial environments, museums or any other scenario one might think of.
Obviously this POS functionality is part of Koo API so it means you can create your own new application taking advantage of touchscreen facilities.
To run koo in pos mode simply run:
python koo.py --pos-mode --stylesheet=Pos/pos.qss
The --pos-mode flag tells koo to show a keyboard or keypad (depending on the field type) each time a text box gets the focus.
The --stylesheet flag tells koo to use the given stylesheet which mainly increases font size and padding so list items are heigher and thus easier to click with the fingers.
This gives developers the chance to use all the flexibility of OpenERP form design to POS but also allows developing touchscreen enabled interfaces for industrial environments, museums or any other scenario one might think of.
Obviously this POS functionality is part of Koo API so it means you can create your own new application taking advantage of touchscreen facilities.
dimecres, 14 / gener / 2009
Integration of Jasper Reports into OpenERP
This time I won't talk about Koo but another project we've started at NaN a few days ago. It's the possibility of using Jasper Reports as any other type of report such as RML.
The module is currently hosted in the server-modules directory of the Koo project at launchpad (https://launchpad.net/openobject-client-kde). Not because both projects have any relation (Jasper Reports work with any OpenERP client you want to use) but because we already had the repository set up.
The module let's you work in two different ways:
In first one, as expected, you create a Jasper report (possibly using iReport) connecting directly to the database through JDBC. Once the user wants to see the report, the jasper_report module will call your report with the connection of the database the user is using in that given time.
The XML based report is much more interesting as it lets you easily browse model fields and relations and add them to the report from within iReport itself. We've kept integration work to a minimum usable and thus it needs some "strange" (though easy) steps before you can use this functionality, but allows for high productivity on report design.
Let's take a look what the steps you need to take to create an XML based jasper report.
The job starts at the Administration -> Custom -> Jasper Reports -> Create Data Template wizard that the jasper_report module adds to OpenERP's menu. We'll choose the main model we want data to come from (and the model in which you'll add the report as any other report type). In this example we'll choose 'res.partner'. You must also select the depth in which you want the file to be created. For example if you want to be able to browse from partner to the country name of an address you need at least depth three (address->country->name). Using depths higher than 5 can be time and resource consuming, depending on the model you start, so take care not to use too high values you most possibly won't need.
Next step of the wizard let's us store an XML file we'll save on disk. ("/tmp/jasper.xml", for example).
Afterwards, we can start iReport and the first thing to do is create an XML datasource pointing to the file we've just stored on disk.
Now you can create a new report, and using the current connection go to edit the report query.
You'll need to choose XPath as query language. On the right, you'll see the XML file structure that matches 'res.partner' model fields and relations. You must select "/data/record" as record node (by right clicking on it, for example). Then you can add all the fields you want to use on the report with their relative path (Note there's a bug in iReport 3.1.2 that forces you to click ok and then edit the query again, otherwise all fields are added with absolute path, which jasper_report module won't accept).
As you can see selecting fields including read-only ones and relations fields is really simple, avoiding lots of SQL joins and searching tables and fields.
Once we have all the fields we want we can use them in the report, and use all iReport/Jasper Reports power, including subreports, charts, crosstabs, etc.
In our example, though we don't want one record per partner, but one record per partner address. In such a case you'll need to add a property to the report called "OPENERP_RELATIONS" as seen in the image below.
Once we've finished the report we can store the ".jrxml" file in our module's directory and write "module_report.xml" file as you would with any other report:
< report string="Jasper Partners" model="res.partner" auto="True" name="res.partner.jaspertest" rml="your_module/partner.jrxml" id="res_partner_jaspertest" menu="True" header="False" />
Now you have your Jasper Report ready to use! And you can freely use SQL and XML based reports as the module automatically knows how to call them.
Note that the module is still under development and there are some known limitations but we think it has a great effort/result ratio because with very little effort we've been able to improve reporting possibilities a lot.
From now on we'll keep improving the module which currently only works (has been tested) with OpenERP 4.2. Of course a higher integration level with iReport would be fantastic but it's not in our road map in the short term. So if anyone is willing to contribute with code or sponsorisation it will be very welcomed.
The module is currently hosted in the server-modules directory of the Koo project at launchpad (https://launchpad.net/openobject-client-kde). Not because both projects have any relation (Jasper Reports work with any OpenERP client you want to use) but because we already had the repository set up.
The module let's you work in two different ways:
- SQL based report
- XML based report
In first one, as expected, you create a Jasper report (possibly using iReport) connecting directly to the database through JDBC. Once the user wants to see the report, the jasper_report module will call your report with the connection of the database the user is using in that given time.
The XML based report is much more interesting as it lets you easily browse model fields and relations and add them to the report from within iReport itself. We've kept integration work to a minimum usable and thus it needs some "strange" (though easy) steps before you can use this functionality, but allows for high productivity on report design.
Let's take a look what the steps you need to take to create an XML based jasper report.
The job starts at the Administration -> Custom -> Jasper Reports -> Create Data Template wizard that the jasper_report module adds to OpenERP's menu. We'll choose the main model we want data to come from (and the model in which you'll add the report as any other report type). In this example we'll choose 'res.partner'. You must also select the depth in which you want the file to be created. For example if you want to be able to browse from partner to the country name of an address you need at least depth three (address->country->name). Using depths higher than 5 can be time and resource consuming, depending on the model you start, so take care not to use too high values you most possibly won't need.
Next step of the wizard let's us store an XML file we'll save on disk. ("/tmp/jasper.xml", for example).
Afterwards, we can start iReport and the first thing to do is create an XML datasource pointing to the file we've just stored on disk.
Now you can create a new report, and using the current connection go to edit the report query.
You'll need to choose XPath as query language. On the right, you'll see the XML file structure that matches 'res.partner' model fields and relations. You must select "/data/record" as record node (by right clicking on it, for example). Then you can add all the fields you want to use on the report with their relative path (Note there's a bug in iReport 3.1.2 that forces you to click ok and then edit the query again, otherwise all fields are added with absolute path, which jasper_report module won't accept).
As you can see selecting fields including read-only ones and relations fields is really simple, avoiding lots of SQL joins and searching tables and fields.
Once we have all the fields we want we can use them in the report, and use all iReport/Jasper Reports power, including subreports, charts, crosstabs, etc.
In our example, though we don't want one record per partner, but one record per partner address. In such a case you'll need to add a property to the report called "OPENERP_RELATIONS" as seen in the image below.
Once we've finished the report we can store the ".jrxml" file in our module's directory and write "module_report.xml" file as you would with any other report:
< report string="Jasper Partners" model="res.partner" auto="True" name="res.partner.jaspertest" rml="your_module/partner.jrxml" id="res_partner_jaspertest" menu="True" header="False" />
Now you have your Jasper Report ready to use! And you can freely use SQL and XML based reports as the module automatically knows how to call them.
Note that the module is still under development and there are some known limitations but we think it has a great effort/result ratio because with very little effort we've been able to improve reporting possibilities a lot.
From now on we'll keep improving the module which currently only works (has been tested) with OpenERP 4.2. Of course a higher integration level with iReport would be fantastic but it's not in our road map in the short term. So if anyone is willing to contribute with code or sponsorisation it will be very welcomed.
diumenge, 28 / desembre / 2008
Model - View
Today I'm going to explain the KooModel class in Koo. This class allows developers to simply create new views that need to display or edit information stored in an OpenERP server. KooModel implements QAbstractItemModel and thus allows to easily use any view that uses Qt's model/view (Including QTreeView, QListView, QTableView and QColumnView). Where easy means changing one (or very few) lines of code to switch from one view to the other.
As an example here you can see how you can modify Koo to use a column view instead of the default tree for menus:
As another example on how to use KooModel, I've created a new application inside the Koo repository. Take a look at this file menu.py.
When executed it will show the following dialog:
As you can see it shows the main application menu. Now one only has to change one line of code to show the same information on a list view.
Or uncomment the three lines of code that would show the chart of accounts:
You can also try the Column View here uncommenting the obvious lines in menu.py.
As you can see this makes it very simple to create small applications inside or outside the ERP to show (or even edit since most recent commits) any information you may need. One example is that sometimes customers want very specific screens that can't be implemented by OpenERP view architecture. This is something that has to be avoided (as it can't be used with other clients) but sometimes it is necessary and if Koo makes it easy, much better!
As an example here you can see how you can modify Koo to use a column view instead of the default tree for menus:
As another example on how to use KooModel, I've created a new application inside the Koo repository. Take a look at this file menu.py.
When executed it will show the following dialog:
As you can see it shows the main application menu. Now one only has to change one line of code to show the same information on a list view.
Or uncomment the three lines of code that would show the chart of accounts:
You can also try the Column View here uncommenting the obvious lines in menu.py.
As you can see this makes it very simple to create small applications inside or outside the ERP to show (or even edit since most recent commits) any information you may need. One example is that sometimes customers want very specific screens that can't be implemented by OpenERP view architecture. This is something that has to be avoided (as it can't be used with other clients) but sometimes it is necessary and if Koo makes it easy, much better!
dijous, 2 / octubre / 2008
Full Text Search
Koo, the KDE OpenObject client has supported Full Text Search for quite some time now. Sadly, it's had very little exposure and not many people know about it. So let me introduce it.
Once installed, the Full Text Search module has to be configured with the fields you want to be indexed in Administration -> Configuration -> Full Text Search -> Indexes. Once you've added all the fields you want to be indexed just execute "Update Full Text Index" in the same menu, and that's it. This will have indexed all existing data and new information introduced will be indexed automatically by a set of triggers created by the module on the database. This means you can even insert records directly to PostgreSQL without fear of making text indexes inconsistent.
Now you can click on the 'Full Text Search' button in Koo to search for any words in any of the indexed fields in any model of the application, including attachments. Double click an item and it will be opened in a new tab. Take a look at these screenshots and screencast.
Using this together with the smart_attach module you can also search inside attached documents information, including images that will be automatically processed with an OCR.
All this, combined with Koo's System Tray functionality, provides a very powerful and easy way for accessing all the information of OpenERP.
The 'full_text_search' server module is included in Koo's bazaar repository so you'll just get it when you download the whole client. You'll also find the 'fts-indexes' module that contains a set of standard preconfigured indexes.
Update: You'll need to configure PostgreSQL in order to be able to use this module. Please take a look at the docs for more info.
Once installed, the Full Text Search module has to be configured with the fields you want to be indexed in Administration -> Configuration -> Full Text Search -> Indexes. Once you've added all the fields you want to be indexed just execute "Update Full Text Index" in the same menu, and that's it. This will have indexed all existing data and new information introduced will be indexed automatically by a set of triggers created by the module on the database. This means you can even insert records directly to PostgreSQL without fear of making text indexes inconsistent.
Now you can click on the 'Full Text Search' button in Koo to search for any words in any of the indexed fields in any model of the application, including attachments. Double click an item and it will be opened in a new tab. Take a look at these screenshots and screencast.
Using this together with the smart_attach module you can also search inside attached documents information, including images that will be automatically processed with an OCR.
All this, combined with Koo's System Tray functionality, provides a very powerful and easy way for accessing all the information of OpenERP.
The 'full_text_search' server module is included in Koo's bazaar repository so you'll just get it when you download the whole client. You'll also find the 'fts-indexes' module that contains a set of standard preconfigured indexes.
Update: You'll need to configure PostgreSQL in order to be able to use this module. Please take a look at the docs for more info.
divendres, 22 / agost / 2008
RPC made even easier
As I exposed in my previous post, the KDE client provides a set of libraries for developers to use to create new applications easily while using the OpenObject server for data storage and management. The module of the library I'll blog about today is Rpc.
RPC itself is pretty easy to use under python if you use XML-RPC for which OpenObject server already provides an interface. But what if you want to use Net-RPC because of its better performance? KDE client RPC library encapuslates the underlaying protocol to the developer and provides an easy to use interface even for asynchronous queries, which let the user interface keep responding while the queries are run in the background.
Before I go into the details let me advise that we're currently working on some API cleanup and consistency checks. Some modules are being renamed and the old 'ktiny' name will be changed to 'Koo' (which stands for 'KDE OpenObject').
That said, let's see a simple example:
Alternatively if you're building a GUI application you may use asynchronous calls like this:
What's interesting about the previous piece of code is that the call is asynchronous but the answer is received synchronously in the GUI process. So you can use GUI functions in the slot that receives the answer, and this works with any of the network protocols supported by Koo.
RPC itself is pretty easy to use under python if you use XML-RPC for which OpenObject server already provides an interface. But what if you want to use Net-RPC because of its better performance? KDE client RPC library encapuslates the underlaying protocol to the developer and provides an easy to use interface even for asynchronous queries, which let the user interface keep responding while the queries are run in the background.
Before I go into the details let me advise that we're currently working on some API cleanup and consistency checks. Some modules are being renamed and the old 'ktiny' name will be changed to 'Koo' (which stands for 'KDE OpenObject').
That said, let's see a simple example:
import Koo.Rpc
session = Koo.Rpc.Session()
session.login( 'http://admin:admin@localhost:8069', 'database' )
#or: session.login( 'socket://admin:admin@localhost:8069', 'database' )
session.call( '/object', 'execute', 'res.partner', 'search', [('name','ilike','NaN')] )
session.logout()
Alternatively if you're building a GUI application you may use asynchronous calls like this:
class MainWindow(QMainWindow):
[...more code here...]
def callbackSlot(self, result):
QMessageBox(self, 'Received', 'The answer was: %s' % result )
def makeCall(self):
session.callAsync( self.callbackSlot, '/object', 'execute', 'res.partner', 'search', [('name','ilike','NaN')] )
What's interesting about the previous piece of code is that the call is asynchronous but the answer is received synchronously in the GUI process. So you can use GUI functions in the slot that receives the answer, and this works with any of the network protocols supported by Koo.
dissabte, 16 / agost / 2008
Self-welcoming
This is my first blog post registed in planet OpenERP. Indeed this is my first blog post, though I've had my blogger account for more than a year now, so time to start using it.
First of all I wanted to thank Fabien for letting NaN participate in the OpenERP community and planet. I think the Tiny company has certainly improved and understood the role of the community in the project and I expect this to result in a benefit for everyone. As already noted by Pedro, the Spanish community has already organized itself with quite success so far, and more to come!
This blog will mostly be about the KDE client we've been developing at NaN with already some help and feedback from the community. Here we have to thank Ferdinand Gassauer, Jordi Esteve and others for their valuable input and bug-hunting.
We want the client not only to integrate nicely within KDE, but it's been succesfully used under Windows and Mac. I think developers should be particularly interested, because more than a powerful client for OpenERP we want to provide a powerful development environment that extends OpenObject power on the desktop. For such a task it provides a Qt based easy to use RPC library, a Qt Item Model and other interesting stuff of which I will talk in subsequent posts.
First of all I wanted to thank Fabien for letting NaN participate in the OpenERP community and planet. I think the Tiny company has certainly improved and understood the role of the community in the project and I expect this to result in a benefit for everyone. As already noted by Pedro, the Spanish community has already organized itself with quite success so far, and more to come!
This blog will mostly be about the KDE client we've been developing at NaN with already some help and feedback from the community. Here we have to thank Ferdinand Gassauer, Jordi Esteve and others for their valuable input and bug-hunting.
We want the client not only to integrate nicely within KDE, but it's been succesfully used under Windows and Mac. I think developers should be particularly interested, because more than a powerful client for OpenERP we want to provide a powerful development environment that extends OpenObject power on the desktop. For such a task it provides a Qt based easy to use RPC library, a Qt Item Model and other interesting stuff of which I will talk in subsequent posts.
Subscriure's a:
Missatges (Atom)
