This subpackage provides encapsulations and entry points for the application itself:
This architecture is meant in particular to provide stability and uniformity accross Odoo major versions, so that the recipe can be leveraged by automated deploymnent tools and continuous integration systems.
Convenience to help some Odoo modules to avoid been imported twice.
Each call of this function returns a boolean indicated whether the specified module was already in the imported_addons registry and add it inconditionnally.
Thus caller code is expected to import the module right away if the return value was False.
Utilities to start a server process.
Bases: distutils.version.Version
Odoo idea of version, wrapped in a class.
This is based on openerp.tools.parse_version(), and Provides straight-ahead comparison with tuples of integers, or distutils Version classes.
Bases: object
A class to give server-level access to one database.
There should be exactly one instance of this class per process. It can be used for any kind of script involving Odoo API, and provides facilities for upgrade scripts (see also :mod:anybox.recipe.odoo.runtime.upgrade)
Before actual use, call open(). Then you’ll have useful attributes and methods reminiscent of the unit test classes:
Example application code:
session.open(db_name="my_db")
admin = session.registry('res_users').browse(session.cr, session.uid, 1)
(...)
session.cr.commit()
session.close()
Transaction management is up to user code
Upgrade scripts writers should check the version handling properties:
Instantiation is done by passing the path to Odoo main configuration file and the path of the buildout directory.
Usually, instantiation code is written by the recipe in the body of the executable “Odoo scripts” it produces. Script writers provide a callable that takes a Session object argument and declare it as a console script entry point in their distribution. End users can reference such entry points in their buildout configurations to have buildout produce the actual executable. See Odoo Scripts for details.
Upgrade scripts are a special case of that process, in which the entry point is actually provided by the recipe and rewraps a user-level source script.
Later versions of the recipe may find a way to pass the whole buildout configuration (recall that this is to be used in a separate process in which the buildout configuration has not been parsed).
Return ir.model.data browse object from its external identifier.
| Parameters: | external_id – External identifier of form module.name. e.g. base.user_root |
|---|---|
| Raise: | ValueError if not found or external_id malformed |
Cleans the thread-local environment.
See init_environments() for more details. This method does nothing if the environments have not been initialized.
| Parameters: | reinit (bool) – if True, init_environments() will be called again after cleaning |
|---|
Close the cursor and forget about the current database.
The session is thus ready to open another database. This methods should be idempotent, wouldn’t fail if the cursor is already closed or the current database is not in registry (either already deleted, or could not be opened at all)
Settable property for version stored in DB of the whole buildout.
This can be thought as the latest version to which the DB has been upgraded to. A simple caching system to avoid querying the DB multiple times is implemented.
Handle prescribed command line options and eat them.
Anything before first occurrence of -- on the command-line is taken into account and removed from sys.argv.
Help messages:
If -h or –help is specified and – is not, the help for the wrapper will be printed, and the -h/–help option kept in sys.argv.
If -h or –help is specified before –, the help for this wrapper will be printed and options after – will be kept in sys.argv.
if -h or –help is specified after –, it will be ignored at this stage, and kept in sys.argv (in most cases triggering help print for the wrapped script).
Enter the environments context manager, but don’t leave it
Automatically called by open() and registry altering methods. See :class:openerp.api.Environment for explanations about environments.
For OpenERP/Odoo versions prior to the new style API merge, this is a no-op.
This thread-local environments is initialized and cleaned with each request in the normal usage of the framework. That’s why is is provided as a context manager.
Therefore, user code probably needs in some case to clean it to avoid side effects. This can be done by calling clean_environments().
Install the modules in the database.
Has the side effect of closing the current cursor, committing if and only if the list of modules is updated.
Demo data loading is handled consistently with the decision taken by open().
| Parameters: |
|
|---|
Compatibility wrapper.
On OpenERP 7, the attribute is __closed but can’t even be accessed if the cursor is closed (OperationalError is raised systematically in sql_db)
On Odoo 8, the attribute is _closed and works correctly.
Load the database
Loading an empty database in Odoo has the side effect of installing the base module. Whether to loading demo data or not has therefore to be decided right away.
| Parameters: |
|
|---|
Property reading the version file from buildout directory.
Comments introduced with a hash are accepted. Only the first significant line is taken into account.
Stable method for downstream code needing to instantiate a version.
This method returns an appropriate version instance, without any dependency on where to import the class from. Especially useful for applications whose life started before this set of utilities has been used : this helps building an usable default.
Return ir.model.data object id from its external identifier.
| Parameters: | external_id – External identifier of form module.name. e.g. base.user_root |
|---|---|
| Raise: | ValueError if not found or external_id malformed |
Update the prescribed modules in the database.
| Parameters: |
|
|---|
Uniform encapsulation of buildout-local upgrade script.
The idea is to provide a common set of options, so that upgrade scripts all have the same interface, and project maintainers can focus on the decision taking logic.
Run the upgrade from a source file.
All arguments are set in the standalone script produced by buildout through entry point options.
upgrade_script: absolute path to the upgrade script python source.
upgrade_callable: name of the callable in source file actually running the script.
It must accept the two following positional arguments, in that order:
- a Session instance (as in standard “Odoo scripts”)
- a logger (standard object from the logging module)
and may return a non zero status code to indicate an error. Both None and 0 are interpreted as success.
conf: path to the Odoo configuration file (managed by the recipe)
buildout_dir: directory of the buildout
This module bridges the classical openerp-server as a console script.
The main() function gets registered on the fly by the server recipe as a console script entry point and used in particular for start_openerp and test_openerp.
Some version independence logic for the startup process also get bootstrapped from here.
Insert arguments in sys.argv (direct impact on child script).
Call the starter script, dispatching configuration.
All arguments are set in the standalone script produced by buildout through entry point options.
| Parameters: |
|
|---|