Download Openerp 6.1

An OpenERP Web addon is simply a Python package with an openerpdescriptor (a __openerp__.py file) which follows a few structuraland namespacing rules.

The OpenERP ETL Client Library is a Python library to extract transform and load dato from any data source to OpenERP Server in an user-friendly way. To use this library you need install etl community module on a OpenERP instance. The OpenERP ETL Client Library is officially supported by Cubic ERP S.A.C. OpenERP Extra Addons 6.1. Contribute to tejastank/openerp-extra-6.1 development by creating an account on GitHub. Openerp 6.1 free download. Fax send for OpenERP Fax send is a module for OpenERP 6.1 for sending faxes using interfax.net. Let’s create first minimal dev module. Example will be for Linux and OpenERP 6.1 rc version. Create dev directory in addons: mkdir addons/dev.

Structure¶

The addon’s descriptor, contains the following information:

name:str

The addon name, in plain, readable english

version:str

The addon version, following Semantic Versioning rules

depends:[str]

A list of addons this addon needs to work correctly. base isan implied dependency if the list is empty.

css:[str]

An ordered list of CSS files this addon provides and needs. Thefile paths are relative to the addon’s root. Because the WebClient may perform concatenations and other variousoptimizations on CSS files, the order is important.

js:[str]

An ordered list of Javascript files this addon provides and needs(including dependencies files). As with CSS files, the order isimportant as the Web Client may perform contatenations andminimizations of files.

active:bool

Whether this addon should be enabled by default any time it isfound, or whether it will be enabled through other means (on aby-need or by-installation basis for instance).

Some of these are guidelines (and not enforced by code), but it’ssuggested that these be followed. Code which does not fit into thesecategories can go wherever deemed suitable.

Namespacing¶

Python¶

Because addons are also Python packages, they’re inherently namespacedand nothing special needs to be done on that front.

JavaScript¶

The JavaScript side of an addon has to live in the namespaceopenerp.$addon_name. For instance, everything created by the addonbase lives in openerp.base.

The root namespace of the addon is a function which takes a singleparameter openerp, which is an OpenERP client instance. Objects(as well as functions, registry instances, etc...) should be added onthe correct namespace on that object.

The root function will be called by the OpenERP Web client wheninitializing the addon.

Creating new standard roles¶

Widget¶

This is the base class for all visual components. It provides a number ofservices for the management of a DOM subtree:

• Rendering with QWeb

• Parenting-child relations

• Life-cycle management (including facilitating children destruction when aparent object is removed)

• DOM insertion, via jQuery-powered insertion methods. Insertion targets canbe anything the corresponding jQuery method accepts (generally selectors,DOM nodes and jQuery objects):

  appendTo()

  Renders the widget and inserts it as the last child of the target, uses.appendTo()

  prependTo()

  Renders the widget and inserts it as the first child of the target, uses.prependTo()

  insertAfter()

  Renders the widget and inserts it as the preceding sibling of the target,uses .insertAfter()

  insertBefore()

  Renders the widget and inserts it as the following sibling of the target,uses .insertBefore()

Widget() inherits fromSessionAware(), so subclasses can easily access theRPC layers.

Subclassing Widget¶

Widget() is subclassed in the standard manner (via theextend() method), and provides a number ofabstract properties and concrete methods (which you may or may not want tooverride). Creating a subclass looks like this:

The new class can then be used in the following manner:

After these two lines have executed (and any promise returned by appendTohas been resolved if needed), the widget is ready to be used.

Note

the insertion methods will start the widget themselves, and willreturn the result of start().

If for some reason you do not want to call these methods, you willhave to first call render() on thewidget, then insert it into your DOM and start it.

If the widget is not needed anymore (because it’s transient), simply terminateit:

will unbind all DOM events, remove the widget’s content from the DOM anddestroy all widget data.

Views¶

Views are the standard high-level component in OpenERP. A view type correspondsto a way to display a set of data (coming from an OpenERP model).

In OpenERP Web, views are standard objects registered against a dedicatedobject registry, so the ViewManager() knows where tofind and how to call them.

Although not mandatory, it is recommended that views inherit fromopenerp.base.View(), which provides a view useful services to itschildren.

Registering a view¶

This is the first task to perform when creating a view, and the simplest byfar: simply call openerp.base.views.add(name,object_path) to registerthe object of path object_path as the view for the view name name.

The view name is the name you gave to your new view in the OpenERP server.

From that point onwards, OpenERP Web will be able to find your object andinstantiate it.

Standard view behaviors¶

In the normal OpenERP Web flow, views have to implement a number of methods soview managers can correctly communicate with them:

This method will always be called after creating the view (via itsconstructor), but not necessarily immediately.

It is called with no arguments and should handle the heavy setup work,including remote call (to load the view’s setup data from the server viae.g. fields_view_get, for instance).

start should return a promise object which must be resolved whenthe view’s setup is completed. This promise is used by view managers toknow when they can start interacting with the view.

Called by the view manager when it wants to replace this view by an otherone, but wants to keep this view around to re-activate it later.

Should put the view in some sort of hibernation mode, and must hide itsDOM elements.

If the view is searchable, this method is called to notify it of a searchagainst it.

It should use the provided query data to perform a search and refresh itsinternal content (and display).

All views are searchable by default, but they can be made non-searchableby setting the property searchable to false.

This can be done either on the view class itself (at the same level asdefining e.g. the start method) or at the instance level (in theclass’s init), though you should generally set it on the class.

Frequent development tasks¶

There are a number of tasks which OpenERP Web developers do or will need toperform quite regularly. To make these easier, we have written a few guidesto help you get started:

Translations¶

OpenERP Web should provide most of the tools needed to correctly translate youraddons via the tool of your choice (OpenERP itself uses Launchpad’s owntranslation tool.

Making strings translatable¶

QWeb¶

QWeb automatically marks all text nodes (any text which is not in an XMLattribute and not part of an XML tag) as translatable, and handles thereplacement for you. There is nothing special to do to mark template text astranslatable

JavaScript¶

OpenERP Web provides two functions to translate human-readable strings injavascript code. These functions should be “imported” in your module byaliasing them to their bare name:

importing those functions under any other name is not guaranteed to work.

Note

only import them if necessary, and only the necessary one(s), no needto clutter your module’s namespace for nothing

Base translation function, eager, works much like gettext(3)

Lazy equivalent to _t(), this function will postponefetching the translation to its argument until the last possible moment.

To use in contexts evaluated before the translation database can befetched, usually your module’s toplevel and the attributes of classesdefined in it (class attributes, not instance attributes set in theconstructor).

Text formatting & translations¶

A difficulty when translating is integrating data (from the code) into thetranslated string. In OpenERP Web addons, this should be done by wrapping thetext to translate in an sprintf(3) call. For OpenERP Web,sprintf(3) is provided by underscore.string.

As much as possible, you should use the “named argument” form of sprintf:

named arguments make the string to translate much clearer for translators, andallows them to “move” sections around based on the requirements of theirlanguage (not all language order text like english).

Named arguments are specified using the following pattern: %($name)$typewhere

$name

the name of the argument, this is the key in the object/dictionary providedas second parameter to sprintf

$type

a type/format specifier, see the list for all possible types.

Note

positional arguments are acceptable if the translated string hasa single argument and its content is easy to guess from the textaround it. Named arguments should still be preferred.

Warning

you should never use string concatenation as it robs thetranslator of context and make result in a completely incorrecttranslation

Extracting strings¶

Once strings have been marked for translation, they need to be extracted intoPOT files, from which most translation toolscan build a database.

This can be done via the provided gen_translations.sh.

It can be called either as gen_translations.sh-a or by providingtwo parameters, a path to the addons and the complete path in which to put theextracted POT file.

Extracts translations from all standard OpenERP Web addons (addons bundledwith OpenERP Web itself) and puts the extracted templates into the rightdirectory for Rosetta to handle them

Utility behaviors¶

JavaScript¶

• All javascript objects inheriting fromopenerp.base.BasicConroller() will have all methodsstarting with on_ or do_ bound to their this. This meansthey don’t have to be manually bound (via _.bind or $.proxy)in order to be useable as bound event handlers (event handlerskeeping their object as this rather than taking whateverthis object they were called with).

  Beware that this is only valid for methods starting with do_ andon_, any other method will have to be bound manually.

Testing¶

Python¶

OpenERP Web uses unittest2 for its testing needs. We selectedunittest2 rather than unittest for the following reasons:

• autodiscovery (similar to nose, via the unit2CLI utility) and pluggable test discovery.
• new and improved assertions (with improvements in type-specificinequality reportings) including pluggable custom types equalityassertions
• neveral new APIs, most notably assertRaises context manager,cleanup function registration, test skipping and class- andmodule-level setup and teardown
• finally, unittest2 is a backport of Python 3’s unittest. We might aswell get used to it.

Openerp Client

To run tests on addons (from the root directory of OpenERP Web) is assimple as typing PYTHONPATH=.unit2discover-saddons[1]. Totest an addon which does not live in the addons directory, simplyreplace addons by the directory in which your own addon lives.

Note

unittest2 is entirely compatible with nose (or theother way around). If you want to use nose as your testrunner (due to its addons for instance) you can simply install itand run nosetestsaddons instead of the unit2 command,the result should be exactly the same.

Python¶

• Addons lifecycle (loading, execution, events, ...)
  • Python-side
  • JS-side
• Handling static files
• Overridding a Python controller (object?)
• Overridding a Javascript controller (object?)
• Extending templates.. how do you handle deploying static files via e.g. a separate lighttpd?
• Python public APIs
• QWeb templates description?
• OpenERP Web modules (from OpenERP modules)

• Apps
  Websites

  Sales

  • Point of Sale

  Operations

  • Human Resources New
  • Manufacturing

  Productivity Tools

  • Communication
  • Marketing New

This module provides a WYSIWYG editor (CKeditor).You need to add in your view's field widget='text_WYSIWYG' to turn the classic textareas into powerful WYSIWYG editors.Then add the following code in those views (this code add the button to switch on/off the WYSIWYG mode)

<html>

<a>WYSIWYG on</a>

Download Openerp 6.1 Software

</html>

So now, in your view you can enable or disable the WYSIWYG editors.

If you download and install the widget 'web_display_html', your fields with widget='text_WYSWYG' will display the HTML instead of the basic text with the tags.

Please log in to comment on this module

• The author can leave a single reply to each comment.
• This section is meant to ask simple questions or leave a rating. Every report of a problem experienced while using the module should be addressed to the author directly (refer to the following point).
• If you want to start a discussion with the author, please use the developer contact information. They can usually be found in the description.