Wednesday, March 16, 2011

Creating Jasper Reports- Installation Guide

  Jasper Reports are mainly used for creating stylish reports other than black and white report. We can add tables, charts,crosstabs etc., in to the jasper report and also we can generate different forms of reports like pdf,xls,html etc. For creating Jasper Report, iReport plays an important role. Using ireport we can simply create Jasper Report. I'm using iReport 4.0.1.
        Jasper report and openERP integration can be done by adding jasper_reports module to our openERP server. Now Open the opneERP client. In  customization menu under the administration menu  we can find the a menu for creating jasper report template.
Pop-up window opened for creating data template
Click on it, provide the model name and depth and then click create. Then an xml file wil be generated. This file is needed for the creating Jasper report. Save the file. For now our  work in the openERP client is completed. Now go to iReport open a newblank report template. Change the datasource or create new datasource by clicking on in iReport toolbar. Add a new xml datasource and providing the path of xml file generated from the openerp client.
xml data source configuring
After creating the xml datasource change the query language by clicking on   
 
in the iReport designer bar. Then a window will open for changing the query language.

window for changing query language

These are the basic things to be done for creating a jasper report. Now we can create a module in our openerp server and start creating jasper report.

Wednesday, February 16, 2011

More on OERPScenario


       Before reading this please read my blog post on OERPScenario . Now go to our OERPScenario folder that we have downloaded from bazaar, there is a folder named features. All the user defined test cases are written in a folder inside this folder. I want to create a new scenarios for testing products, so I create a directory called product inside features. Inside the product directory a file called product.feature is created. We have to write our scenarios in this file.

       In writing the scenario we are following the Gherkin Syntax. Gherkin is the language that Cucumber and OERPScenario can understand. The source files have *.feature extension. Gherkin is a line-oriented language that uses indentation to define structure. Most lines start with a keyword.
   
       For writing the scenario I'm creating a file called product.feature inside the folder product. In writing the scenario first write <Feature:> explaining about the scenario. Then our scenario <Scenario:>.Statements following the scenario must start with any of the keyword 'Given', 'When', 'Then' or 'And'. 'And' can be used for extending 'Given' , 'When' and 'Then'.The following figure will give an idea  about each keyword.



 Before writing the feature, tags are given and this tag can be used for testing the scenarios under this feature. We can also specify tags for each scenario and by using this tags we can test the scenario that come under this tag. The statements written between Feature and Scenario are omitted by the cucumber. So we don't need to concentrate much on it. After writing the scenarios we can run the scenarios. But before running the scenario we have to compile the whole OERPScenario  folder using the command rake compile.This is just for testing the connection between openERP server and OERPScenario. If this fails then everything fails(I think so).
When I was testing I  found that the scenario written inside  the file  _init.rb  in feature>_basic>step_definions did not satisfy the conditions written inside the  _init.feature file in feature>_basic. So I changed the code . Figure of the changed code is given below
After all the changes are made, we can compile it using command rake compile. If we get all test scenarios printed in green color then we can proceed. If we get it in red color then an error is present in it.

Now we  can run our scenario.


By running this the test cases that needed for testing product are automatically generated by the cucumber. Copy these test cases and paste them to a ruby file (say product_steps.rb) created inside a directory called "step_definition" inside product.  

//not completed

OERP Scenario

       In OpenERP a time consuming task is to check all the modules by entering data to each field and checking whether the view is changing according to the data given in the field or changing according to our plan. It is also not possible to check all the information given in the fields. And also testing is important in locating a bug and fixing an error. For this purpose we are using OERPScenario. OERPScenario do the same process as the database query do. OERPScenario search for the condition data from the database satisfying the scenario statements.

      OERPScenario allowing to write business oriented test cases in OpenERP. OERPScenario is a framework based on the Cucumber Library and the Ruby Language; it uses the Ooor connector developed by Akretion to make Business Driven Development (BDD) among OpenERP. It is a tool that can execute plain-text functional descriptions as automated tests.

 OERPScenario splits tasks in two, allowing business individuals to write and describe the different test scenarios, while technical individuals code the tests.

Install and Configure OERPScenario in Ubuntu 10.04

==$sudo apt-get install ruby irb ri rdoc rubygems
==$sudo gem install cucumber -v0.6.3
==$sudo gem install rspec
==$sudo gem install parseconfig
==$sudo gem install ooor --source http://gemcutter.org
==$sudo apt-get install libopenssl-ruby
==$sudo gem install rake
==$sudo gem install htmlentities
==$# Optional for pdf output only
==$sudo gem install prawn --version 0.6.3
==$sudo gem install prawn-format --version 0.2.3
==$# Finally add '/var/lib/gems/1.8/bin' to your PATH :
==$export PATH=$PATH:/var/lib/gems/1.8/bin

Then install the "bzr" for downloading the OERPScenario. After installing "bzr" retrieve the stable branch:
==$bzr branch lp:oerpscenario

Configure

We need to instruct OERPScenario on how to connect to the OpenERP server in a
configuration file. In order to do that, copy the file « sample_base.conf » as «base.conf » into the OERPScenario folder and change the following information according to your settings:
port = 8069
user = «username »
#if it is administrator then provide "admin"
database = «mydatabasename »
password = «secrete »
host = localhost

Once it's done, go into the OERPScenario folder and run the following command to test the connection:
==$rake compile
You should then have an output confirming everything is alright.

As the tests are running under a specific user, you can always change the one that has been set-up as default (by default, all tests are running with the user defined in the config file). If you need to run the tests under another user, edit the following file:
« /features/_basic/_init.feature » and change the sentence according to your needs

The configuration is done!

Using tags

 The tag system implemented in Cucumber is very powerful and allows you to run complex test cases according to your own OpenERP settings. Basically, the following tag types are present in OERPScenario:
• Bazaar branch (like @addons), which tests all existing modules in that branch;
• Modules (likes @account), which tests everything having to do with a specific
   module;
• Bugs related (like @bug452854), which launches the related scenario;
• Business oriented (like @invoicing), which runs every related scenario;
• System (like @init, @demo), which executes a set of tasks in OpenERP.

Launching the OERPScenario
 You can launch the test suite from the OERPScenario folder with the following commands:
cucumber feature --tag=@account
This will execute all scenarios related to the OpenERP account module (notice that tags can be set on features or scenarios). The feature tags are true for all included scenarios, where the scenario tags are true only for the current scenario.


Friday, January 28, 2011

Wizards and Links in openERP

    Wizard describe interaction sequences between the client and the server. Wizards provide a form for the client to complete it. Then client can sent the completed form back to the server and server executes some function and return another form to the user or will save the information provided by the client in the database.

To define a wizard, you have to create a class inheriting from wizard.interface and instantiate it. Each wizard must have a unique name. The wizard must define a dictionary named states which defines all its steps. 


 The ‘states’ dictionary define all the states of the wizard.In this example; init, test1, test2 and test3.
 A wizard always starts in the init state and ends in the end state. A state defines two things: a list of actions and a result.
  • List of actions: Each state of a wizard defines a list of actions which are executed when the wizard enters the state. This list can be empty.
  • Result : Specifies the next state/step. The wizard will continue to the next state and if the next state given is "end" then the wizard will stop.

    • The result have different types. They are form, action, choice, print etc.
    • If the type is form then the client will get a form view. 
    • If the type is action then a user_defined_function(action) will be executed and the resulting action will be performed.
    • If the type is choice then also a function will be executed. This function will return the name of the next state of the wizard.
    • If the type is print then we have to provide the name of the report to be printed.

  The type=form indicate that this step is a dialog to the client. We have to provide the fields and the xml view part inside our wizard.


Each step/state of a wizard can have several buttons.Those are located on the bottom right of the dialog box. The list of buttons for each step of the wizard is declared in the state key of its result dictionary.



  • the next step name (determine which state will be next)



  • the button string (to display for the client)



  • the gtk stock item without the stock prefix



  • Dynamic Forms and Fields in Wizard

    Here I create a function "_get_defaults" which returns a dictionary  self.states['test']['result']. Here I'm dynamically providing values to the dictionary "states". The function "_get_defaults" given below.

     The function gets the limit of fields and forms from the previous wizard state using its field name mainly I'm assuming that the data to be added to the field is a character field and I had created the fields according to this assumption. Try yourself and find out its output.


    The XML file

            After completing the code in the wizard we have to add the wizard to the view part. We have to add the following statement to the xml file for getting the wizard in the client interface

    --->id--> id is just a unique name.
    --->model-->model is the place where we want to display the wizard.
    --->name-->name given here is passed in the instance of the class test_wizard_college

    By adding the following statement inside our student view a new button will be created inside . 

     If we want the wizard as a menu item then


     here action is the wizard id, and parent is given as the root menu


     LINKS
            A link is different from wizard. A link creates a connection to a model from a model. To add a link from one model to another model we have to use act_window

    Here res_model is the resulting model in which the link will take us to this model, src_model is the source model in which where the link will be shown.

    Wednesday, January 5, 2011

    Reports In openERP

          This feature helps to create PDF reports. Data taken from our database can be used to create reports. To create a report we need a rml file. The rml file can be generated from sxw file. More about sxw file is explained later in this blog.

          First of all create a new directory called “report” inside our module. Then create an init file and import the file names of the files that we are going to use for report generation. We have to also update the init file of our module. That is we have to import the folder name "report" in the init file. 
    The python program is give below.

    We have to import report_sxw from report and osv from osv.

    class test_parser(report_sxw.rml_parse):-->we have to inherit the class report_sxw.rml_parse. 

    super(test_parser, self).__init__(cr, uid, name, context=context)--->here is the function overiding
     
    self.localcontext.update({})--> Inside braces if we are defining any functions for taking data from the database then we have to specify the function names here.
     
    report_sxw.report_sxw('report.test_report','student.class','addons/dec13/report/new_details.rml',parser=test_parser)-->The instance of the function is called here. Parameters passing here are name of the report, Which class is using this, its rml file location, then the parser(the class which create the report).

    Before reloading the server we have to generate the rml file from the sxw file. Open office helps to create the sxw file. Create the sxw file inside our module's report folder. Static information can be added by typing inside the sxw file.For dynamic information we have to use the following method.

    [[repeatIn(objects,'o')]] --> Inside 2 square brackets(tagging) add repeatIn(). This will help to take data from the database. RepeatIn works same like browse(). The first parameter can be objects, function name etc. Second parameter is the short_name used for calling the object. If no function is defined in report then the object of the class in which we are using the report is passed as the object and we can use each field using short_name.field_name. 

    Name:[[o.name]] --> Name is the text and o.name take the value from the database where fieldname= name
     If the field defined is one2many or many2many, then we have to first create a section in the sxw file and inside this define repeatIn() with the o.field_name as its first parameter.  

    To convert the *.sxw to *.rml first locate the directory “openerp_sxw2rml” copy  file openerp_sxw2rml.py, [normalized_odt2rml.xsl and normalized_oo2rml.xsl --sometimes these two files will be needed]  to our report folder. Then  
    ./openerp_sxw2rml.py file_name.sxw > file_name.rml  
    will convert the sxw file to rml file.


    Now we have completed 80% of our report creation. We have to add report feature to our view. Go to our xml file(or create a new xml file add this xml file name to the terp file).
     <openerp>
    <data>
       <report id="some_unique_id"
              string="Name_in_the_menu_that_calls_the_report"
              model="name_of_the_model_in_which_the_report_will_be_rendered"
              name="name_of_the_file"
              rml="PATH/filename.rml"    <!--PATH is relative to addons/ directory-->
              menu="True"    <!--whether the report will be able to be called directly via the client or not.  Setting menu to False is useful in case of reports called bywizards.-->
              auto="False"/>
     </data>
    </openerp> 
      

    This will create a menu inside the model we have specified. By clicking this field a pdf file will be opened with the values we have specified in the sxw file.

    Tuesday, December 28, 2010

    Python files in openERP

    All the necessary files needed for creating the module and connecting with the  view lies under the base module. Base module contain a folder called osv in which all the functions and classes needed for creating a model is defined here. So first of all Import fields and osv from osv.

    To define a new object, you have to define a new Python class then instantiate it. This class must inherit from the osv class in the osv module.The first line of the object definition will always be of the form:
    An object is defined by declaring some fields with predefined names in the class. Two of them are required (_name and _columns), the rest are optional. The predefined fields are:
    • _auto
    • _columns (required)
    • _constraints
    • _sql_constraints
    • _defaults
    • _inherit
    • _inherits
    • _log_access
    • _name (required)
    • _order
    • _rec_name
    • _sequence
    • _sql
    • _table
    In the database, tables will be created with the table name given in the _name field (all the dot"." will be replaced by underscore"_" in table creation)

    Fields for the database table is specified inside the "_columns". Columns is an associative array(dictionary) in which we specify the field name as the key and field type as the value.

    Types of fields
    Basic types
    boolean:
    A boolean (true, false).
    Syntax:
    fields.boolean('Field Name' [, Optional Parameters]),
     
    integer:
    An integer.
    Syntax:
    fields.integer('Field Name' [, Optional Parameters]),
     
    float:
    A floating point number.
    Syntax:
    fields.float('Field Name' [, Optional Parameters]),
    
    char:
    A string of limited length. The required size parameter determines its size.
    Syntax:
    fields.char(
            'Field Name',
            size=n [,
            Optional Parameters]), # where ''n'' is an integer.
    text:
    A text field with no limit in length.
    Syntax:
    fields.text('Field Name' [, Optional Parameters]),
     
    date:
    A date.
    Syntax:
    fields.date('Field Name' [, Optional Parameters]),
     
    datetime:
    Allows to store a date and the time of day in the same field.
    Syntax:
    fields.datetime('Field Name' [, Optional Parameters]),
     
    binary:
    A binary chain. We can import(upload) our files using binary.
    selection:
    A field which allows the user to make a selection between various predefined values.
    Syntax:
    fields.selection((('n','Unconfirmed'), ('c','Confirmed')),
                       'Field Name' [, Optional Parameters]),
     
    Relational fields

    • one2many and many2one
      • An example is relationship between employee and department. A department may have so many employees and employees will belong to only one department.
      • When defining a many2one relationship in open erp, at first there must have a one2many relationship. ie the constructor which have the one2many relation must be called before calling the constructor having many2one relation.

      • {"employee":fields.one2many("employee.class","department_id","Employees")}

    In class department we define the field as dictionary values, “employee” as the key, “fields.one2many()” as the value with 3parameters. First parameter is the other class name(here employee.class ), then the key name of the other class which has the many2one as its value(here employee_id), then the field name.
      • {"department_id":fields.many2one("department.class","Department"),}

                In class employee we define the field as dictionary values, “department_id” as the key, “field.many2one()” as the value with 2parameters. First parameter is the other class name(here is the department.class) then the field name.

    • many2many
      • Example is the relationship between user and group. Users may belong to so many groups and a group may have so many users.
      • For showing a many2many relationship, we have to create a new relationship table in the database with fields user_id and group_id.
      • If we want a many2many relation between two classes say class abc and class xyz then we have to first define both classes. Now add the many2many relationship in the class which secondly created( here class xyz). Now define a new class which inherit the properties of the class abc. Define the many2many relationship here in the inherited class.
      
      • { 'user_ids': fields.many2many('group.class','user_group_rel', 'user_id','group_id','Users')}
      • The parameters are
        • other class name
        • relationship table name
        • my_relation_id
        • other_relation_id
        • field name

    OpenERP(open Enterprise Resourse Planning)

            OpenERP is an open source comprehensive suite of business applications including Sales, CRM(Customer Relationship management), Project management, Warehouse management, Manufacturing, Accounting and Human Resources. OpenERP has separate client and server components. XML-RPC interfaces are available. It is based on a strong MVC architecture, flexible workflows, a dynamic GUI, an XML-RPC interface, and customizable reporting system with convenient OpenOffice.org integration.

    An OpenERP system has three main components :
    1. PostgreSQL dataserver which has all the databases
    2. OpenERP application server that has all of the enterprise logic
    3. web server, a distinct application called the Open Object client-web, which allows you to connect to OpenERP from any web browser. This is not needed if the user connect through a GTK client.
             The server part is written in Python. Business functionality is organized into "modules". A module is a folder with a pre-defined structure containing Python code and XML files. A module defines data structure, forms, reports, menus, procedures, workflows etc. The client is thin as it contains no business logic. 

    Working 
            I am using eclipse IDE for editing and using openERP version 5.0.14. We can download the server and client package from www.openerp.com , unzip the files and start the server. To start the server first go the openerp-server folder, then to the bin folder. There you can find the openerp-server.py 

         will run the server. Same process for running the client. We can find a file named openerp-client.py inside the bin folder present in the client. Provide the "-v" option to get the complete details of the module fields when mouse pointer pointed to it. Then a client interface with a pop-up window for login. If the database is not present or server is not yet started a error message will be shown. In openERP for the database creation postgresql is used. If there is no error then interface with all the functionalies will be shown.
    This is the login window.
            Open eclipse and select the work space. The server code must be inside the workspace folder found in the home folder. After opening the eclipse go to the folder /bin/addons inside our openerp-server-5.x.x. The addons folder contains all the modules created by the openerp team. We have to add our module in this folder. Create a new directory and inside this directory we have to create all supporting files needed for our module.

    Basic files needed for a module are
    1. __init__.py  -->In this file we have to specify the all the files needed for our module. That is we have to import all the needed *.py file names and folder names inside this init file.
    2. __terp__.py  -->This is the configuration file.Here we have to specify all the files and depending modules,demo files, author name, version etc.
    3. *.py file . --> In the .py file we define our model, and controller.
    4. *.xml file.--->The view part is defined in .xml files.
        ____________________________________________________________________________