-* ``model`` is the name of the Odoo model for the record.
+* ``model`` is the name of the Flectra model for the record.
* ``id`` is an :term:`external identifier`, it allows referring to the record
(without having to know its in-database identifier).
* ```` elements have a ``name`` which is the name of the field in the
@@ -454,7 +454,7 @@ composed of fields defining which fields can be searched on:
-If no search view exists for the model, Odoo generates one which only allows
+If no search view exists for the model, Flectra generates one which only allows
searching on the ``name`` field.
.. exercise:: Search courses
@@ -501,16 +501,16 @@ between different models.
Relational field types are:
-:class:`Many2one(other_model, ondelete='set null') `
+:class:`Many2one(other_model, ondelete='set null') `
A simple link to an other object::
print foo.other_id.name
.. seealso:: `foreign keys `_
-:class:`One2many(other_model, related_field) `
- A virtual relationship, inverse of a :class:`~odoo.fields.Many2one`.
- A :class:`~odoo.fields.One2many` behaves as a container of records,
+:class:`One2many(other_model, related_field) `
+ A virtual relationship, inverse of a :class:`~flectra.fields.Many2one`.
+ A :class:`~flectra.fields.One2many` behaves as a container of records,
accessing it results in a (possibly empty) set of records::
for other in foo.other_ids:
@@ -518,11 +518,11 @@ Relational field types are:
.. danger::
- Because a :class:`~odoo.fields.One2many` is a virtual relationship,
- there *must* be a :class:`~odoo.fields.Many2one` field in the
+ Because a :class:`~flectra.fields.One2many` is a virtual relationship,
+ there *must* be a :class:`~flectra.fields.Many2one` field in the
:samp:`{other_model}`, and its name *must* be :samp:`{related_field}`
-:class:`Many2many(other_model) `
+:class:`Many2many(other_model) `
Bidirectional multiple relationship, any record on one side can be related
to any number of records on the other side. Behaves as a container of
records, accessing it also results in a possibly empty set of records::
@@ -582,7 +582,7 @@ Inheritance
Model inheritance
-----------------
-Odoo provides two *inheritance* mechanisms to extend an existing model in a
+Flectra provides two *inheritance* mechanisms to extend an existing model in a
modular way.
The first inheritance mechanism allows a module to modify the behavior of a
@@ -603,13 +603,13 @@ fields of the parent record.
.. seealso::
- * :attr:`~odoo.models.Model._inherit`
- * :attr:`~odoo.models.Model._inherits`
+ * :attr:`~flectra.models.Model._inherit`
+ * :attr:`~flectra.models.Model._inherits`
View inheritance
----------------
-Instead of modifying existing views in place (by overwriting them), Odoo
+Instead of modifying existing views in place (by overwriting them), Flectra
provides view inheritance where children "extension" views are applied on top of
root views, and can add or remove content from their parent.
@@ -693,7 +693,7 @@ instead of a single view its ``arch`` field is composed of any number of
Domains
#######
-In Odoo, :ref:`reference/orm/domains` are values that encode conditions on
+In Flectra, :ref:`reference/orm/domains` are values that encode conditions on
records. A domain is a list of criteria used to select a subset of a model's
records. Each criteria is a triple with a field name, an operator and a value.
@@ -756,7 +756,7 @@ retrieved from the database but computed on-the-fly by calling a method of the
model.
To create a computed field, create a field and set its attribute
-:attr:`~odoo.fields.Field.compute` to the name of a method. The computation
+:attr:`~flectra.fields.Field.compute` to the name of a method. The computation
method should simply set the value of the field to compute on every record in
``self``.
@@ -775,7 +775,7 @@ method should simply set the value of the field to compute on every record in
.. code-block:: python
import random
- from odoo import models, fields, api
+ from flectra import models, fields, api
class ComputedModel(models.Model):
_name = 'test.computed'
@@ -793,11 +793,11 @@ Dependencies
The value of a computed field usually depends on the values of other fields on
the computed record. The ORM expects the developer to specify those dependencies
-on the compute method with the decorator :func:`~odoo.api.depends`.
+on the compute method with the decorator :func:`~flectra.api.depends`.
The given dependencies are used by the ORM to trigger the recomputation of the
field whenever some of its dependencies have been modified::
- from odoo import models, fields, api
+ from flectra import models, fields, api
class ComputedModel(models.Model):
_name = 'test.computed'
@@ -849,7 +849,7 @@ float, string), or a function taking a recordset and returning a value::
.. exercise:: Active objects – Default values
* Define the start_date default value as today (see
- :class:`~odoo.fields.Date`).
+ :class:`~flectra.fields.Date`).
* Add a field ``active`` in the class Session, and set sessions as active by
default.
@@ -859,7 +859,7 @@ float, string), or a function taking a recordset and returning a value::
.. note::
- Odoo has built-in rules making fields with an ``active`` field set
+ Flectra has built-in rules making fields with an ``active`` field set
to ``False`` invisible.
Onchange
@@ -872,7 +872,7 @@ to the database.
For instance, suppose a model has three fields ``amount``, ``unit_price`` and
``price``, and you want to update the price on the form when any of the other
fields is modified. To achieve this, define a method where ``self`` represents
-the record in the form view, and decorate it with :func:`~odoo.api.onchange`
+the record in the form view, and decorate it with :func:`~flectra.api.onchange`
to specify on which field it has to be triggered. Any change you make on
``self`` will be reflected on the form.
@@ -914,17 +914,17 @@ the ``taken_seats`` progressbar is automatically updated.
Model constraints
=================
-Odoo provides two ways to set up automatically verified invariants:
-:func:`Python constraints ` and
-:attr:`SQL constraints `.
+Flectra provides two ways to set up automatically verified invariants:
+:func:`Python constraints ` and
+:attr:`SQL constraints `.
A Python constraint is defined as a method decorated with
-:func:`~odoo.api.constrains`, and invoked on a recordset. The decorator
+:func:`~flectra.api.constrains`, and invoked on a recordset. The decorator
specifies which fields are involved in the constraint, so that the constraint is
automatically evaluated when one of them is modified. The method is expected to
raise an exception if its invariant is not satisfied::
- from odoo.exceptions import ValidationError
+ from flectra.exceptions import ValidationError
@api.constrains('age')
def _check_something(self):
@@ -943,7 +943,7 @@ raise an exception if its invariant is not satisfied::
.. patch::
SQL constraints are defined through the model attribute
-:attr:`~odoo.models.Model._sql_constraints`. The latter is assigned to a list
+:attr:`~flectra.models.Model._sql_constraints`. The latter is assigned to a list
of triples of strings ``(name, sql_definition, message)``, where ``name`` is a
valid SQL constraint name, ``sql_definition`` is a table_constraint_ expression,
and ``message`` is the error message.
@@ -1265,7 +1265,7 @@ rights are usually created by a CSV file named after its model:
access_idea_idea,idea.idea,model_idea_idea,base.group_user,1,1,1,0
access_idea_vote,idea.vote,model_idea_vote,base.group_user,1,1,1,0
-.. exercise:: Add access control through the Odoo interface
+.. exercise:: Add access control through the Flectra interface
Create a new user "John Smith". Then create a group
"OpenAcademy / Session Read" with read access to the *Session* model.
@@ -1310,7 +1310,7 @@ access rights are limited.
Here is an example of a rule that prevents the deletion of leads that are not
in state ``cancel``. Notice that the value of the field ``groups`` must follow
-the same convention as the method :meth:`~odoo.models.Model.write` of the ORM.
+the same convention as the method :meth:`~flectra.models.Model.write` of the ORM.
.. code-block:: xml
@@ -1343,9 +1343,9 @@ Wizards
Wizards describe interactive sessions with the user (or dialog boxes) through
dynamic forms. A wizard is simply a model that extends the class
-:class:`~odoo.models.TransientModel` instead of
-:class:`~odoo.models.Model`. The class
-:class:`~odoo.models.TransientModel` extends :class:`~odoo.models.Model`
+:class:`~flectra.models.TransientModel` instead of
+:class:`~flectra.models.Model`. The class
+:class:`~flectra.models.TransientModel` extends :class:`~flectra.models.Model`
and reuse all its existing mechanisms, with the following particularities:
- Wizard records are not meant to be persistent; they are automatically deleted
@@ -1432,38 +1432,38 @@ Internationalization
Each module can provide its own translations within the i18n directory, by
having files named LANG.po where LANG is the locale code for the language, or
the language and country combination when they differ (e.g. pt.po or
-pt_BR.po). Translations will be loaded automatically by Odoo for all
+pt_BR.po). Translations will be loaded automatically by Flectra for all
enabled languages. Developers always use English when creating a module, then
-export the module terms using Odoo's gettext POT export feature
+export the module terms using Flectra's gettext POT export feature
(:menuselection:`Settings --> Translations --> Import/Export --> Export
Translation` without specifying a language), to create the module template POT
file, and then derive the translated PO files. Many IDE's have plugins or modes
for editing and merging PO/POT files.
-.. tip:: The Portable Object files generated by Odoo are published on
- `Transifex `__, making it
+.. tip:: The Portable Object files generated by Flectra are published on
+ `Transifex `__, making it
easy to translate the software.
.. code-block:: text
|- idea/ # The module directory
|- i18n/ # Translation files
- | - idea.pot # Translation Template (exported from Odoo)
+ | - idea.pot # Translation Template (exported from Flectra)
| - fr.po # French translation
| - pt_BR.po # Brazilian Portuguese translation
| (...)
.. tip::
- By default Odoo's POT export only extracts labels inside XML files or
+ By default Flectra's POT export only extracts labels inside XML files or
inside field definitions in Python code, but any Python string can be
- translated this way by surrounding it with the function :func:`odoo._`
+ translated this way by surrounding it with the function :func:`flectra._`
(e.g. ``_("Label")``)
.. exercise:: Translate a module
- Choose a second language for your Odoo installation. Translate your
- module using the facilities provided by Odoo.
+ Choose a second language for your Flectra installation. Translate your
+ module using the facilities provided by Flectra.
.. only:: solutions
@@ -1486,7 +1486,7 @@ for editing and merging PO/POT files.
terms
#. In ``models.py``, add an import statement for the function
- ``odoo._`` and mark missing strings as translatable
+ ``flectra._`` and mark missing strings as translatable
#. Repeat steps 3-6
@@ -1501,7 +1501,7 @@ Reporting
Printed reports
---------------
-Odoo 11.0 uses a report engine based on :ref:`reference/qweb`,
+Flectra 11.0 uses a report engine based on :ref:`reference/qweb`,
`Twitter Bootstrap`_ and Wkhtmltopdf_.
A report is a combination two elements:
@@ -1625,13 +1625,13 @@ Business objects can also be accessed via the distributed object
mechanism. They can all be modified via the client interface with contextual
views.
-Odoo is accessible through XML-RPC/JSON-RPC interfaces, for which libraries
+Flectra is accessible through XML-RPC/JSON-RPC interfaces, for which libraries
exist in many languages.
XML-RPC Library
---------------
-The following example is a Python 3 program that interacts with an Odoo
+The following example is a Python 3 program that interacts with an Flectra
server with the library ``xmlrpc.client``::
import xmlrpc.client
@@ -1653,7 +1653,7 @@ server with the library ``xmlrpc.client``::
.. exercise:: Add a new service to the client
Write a Python program able to send XML-RPC requests to a PC running
- Odoo (yours, or your instructor's). This program should display all
+ Flectra (yours, or your instructor's). This program should display all
the sessions, and their corresponding number of seats. It should also
create a new session for one of the courses.
@@ -1701,7 +1701,7 @@ server with the library ``xmlrpc.client``::
JSON-RPC Library
----------------
-The following example is a Python 3 program that interacts with an Odoo server
+The following example is a Python 3 program that interacts with an Flectra server
with the standard Python libraries ``urllib.request`` and ``json``::
import json
@@ -1742,19 +1742,19 @@ Examples can be easily adapted from XML-RPC to JSON-RPC.
.. note::
- There are a number of high-level APIs in various languages to access Odoo
+ There are a number of high-level APIs in various languages to access Flectra
systems without *explicitly* going through XML-RPC or JSON-RPC, such as:
* https://github.com/akretion/ooor
* https://github.com/syleam/openobject-library
* https://github.com/nicolas-van/openerp-client-lib
- * http://pythonhosted.org/OdooRPC
+ * http://pythonhosted.org/FlectraRPC
* https://github.com/abhishek-jaiswal/php-openerp-lib
.. [#autofields] it is possible to :attr:`disable the automatic creation of some
- fields `
+ fields `
.. [#rawsql] writing raw SQL queries is possible, but requires care as it
- bypasses all Odoo authentication and security mechanisms.
+ bypasses all Flectra authentication and security mechanisms.
.. _database index:
http://use-the-index-luke.com/sql/preface
diff --git a/doc/howtos/themes.rst b/doc/howtos/themes.rst
index 30583cfd..fb4f3599 100644
--- a/doc/howtos/themes.rst
+++ b/doc/howtos/themes.rst
@@ -6,10 +6,10 @@ Theme Tutorial
.. rst-class:: lead
-Odoo celebrates freedom. Freedom for the designer to go further and
+Flectra celebrates freedom. Freedom for the designer to go further and
freedom for the user to customize everything according to their needs.
-Ready to create your own theme? Great. Here are some things you should know before you begin. This tutorial is a guide to creating an Odoo theme.
+Ready to create your own theme? Great. Here are some things you should know before you begin. This tutorial is a guide to creating an Flectra theme.
.. image:: theme_tutorial_assets/img/Intro.jpg
@@ -17,14 +17,14 @@ Ready to create your own theme? Great. Here are some things you should know befo
An introduction for web designers
=================================
-If you are a web designer using Odoo for the first time, you are in the right place.
-This introduction will outline the basics of Odoo theme creation.
+If you are a web designer using Flectra for the first time, you are in the right place.
+This introduction will outline the basics of Flectra theme creation.
.. note::
- Odoo’s team has created a framework that’s powerful and easy to use. There’s no need to know special syntaxes to use this set of tools.
+ Flectra’s team has created a framework that’s powerful and easy to use. There’s no need to know special syntaxes to use this set of tools.
-From common CMS to Odoo
+From common CMS to Flectra
-----------------------
.. note::
@@ -35,7 +35,7 @@ From common CMS to Odoo
Where is my header.php file?
-This is usually the first question from a web designer used to working with Wordpress or Joomla and coming to Odoo for the first time.
+This is usually the first question from a web designer used to working with Wordpress or Joomla and coming to Flectra for the first time.
.. container:: row
@@ -47,23 +47,23 @@ This is usually the first question from a web designer used to working with Word
Indeed, when using common CMSs, you have to code several files (like header.php, page.php, post.php, etc.) in order to create a basic structure for your website. With those systems, this base structure acts as a design foundation that you have to update over time to ensure compatibility within your CMS. So, even after you have spent hours coding the files, you have not even started on the design yet.
- This **does not** apply to creating Odoo themes.
+ This **does not** apply to creating Flectra themes.
.. note::
We think that theme design should be simple (and powerful). When we created our Website Builder, we decided to start from scratch instead of relying on what already existed. This approach gave us the freedom to focus on the things that are really important for designers: styles, content and the logic behind them. No more struggling with technical stuff.
-Odoo default theme structure
+Flectra default theme structure
----------------------------
.. container:: row
.. container:: col-sm-8
- Odoo comes with a default theme structure.
+ Flectra comes with a default theme structure.
It is a very basic “theme” that provides minimal structure and layout. When you create a new theme, you are actually extending this.
Indeed it’s always enabled in your setup and it acts exactly like the CMS’s base structure we mentioned above, except that you don’t have to create or maintain it.
- It will upgrade automatically within your Odoo installation and, since it is included in the Website Builder module, everything is smoothly integrated by default.
+ It will upgrade automatically within your Flectra installation and, since it is included in the Website Builder module, everything is smoothly integrated by default.
As a result, you are totally free to focus on design while this structure does the job of providing integrations and functionality.
@@ -95,14 +95,14 @@ Odoo default theme structure
Thinking "modular"
==================
-An Odoo theme is not a folder containing HTML or PHP files, it’s a modular framework written in XML. Never worked with XML files before? Don’t worry, after following the tutorial, you’ll be able to create your first theme with only basic knowledge of HTML.
+An Flectra theme is not a folder containing HTML or PHP files, it’s a modular framework written in XML. Never worked with XML files before? Don’t worry, after following the tutorial, you’ll be able to create your first theme with only basic knowledge of HTML.
Using classical web design workflows, you usually code the layout of the entire page. The result of this is a “static” web page. You can update the content, of course, but your client will need you to work on making even basic changes.
-Creating themes for Odoo is a total change of perspective. Instead of defining the complete layout for a page, you can create blocks (snippets) at let the user choose where to “drag&drop” them, creating the page layout on their own.
+Creating themes for Flectra is a total change of perspective. Instead of defining the complete layout for a page, you can create blocks (snippets) at let the user choose where to “drag&drop” them, creating the page layout on their own.
We call this modular design.
-Imagine an Odoo theme as a “list” of elements and options that you have to create and style.
+Imagine an Flectra theme as a “list” of elements and options that you have to create and style.
As a designer, your goal is to style these elements in order to achieve a wonderful result, regardless of where the end user chooses to place them.
Let’s take a tour of our “list” elements:
@@ -141,24 +141,24 @@ Let’s take a tour of our “list” elements:
Functionalities
- Thanks to Odoo’s modularity, everything can be personalized even more. This means there are endless possibilities for your creativity. Adding functionalities is easy and it’s simple to provide the end user with customizable options.
+ Thanks to Flectra’s modularity, everything can be personalized even more. This means there are endless possibilities for your creativity. Adding functionalities is easy and it’s simple to provide the end user with customizable options.
-Odoo's XML files, an overview
+Flectra's XML files, an overview
-----------------------------
-Any Odoo XML file starts with encoding specifications.
-After that, you have to write your code inside a ```` tag.
+Any Flectra XML file starts with encoding specifications.
+After that, you have to write your code inside a ```` tag.
.. code-block:: xml
[XML]
-
+
## YOUR CODE HERE
-
+
Almost every element and option that you create has to be placed inside a ```` tag, like in this example.
@@ -178,7 +178,7 @@ Almost every element and option that you create has to be placed inside a ``
-
+
-
+
-Create a new template into the ```` tag, copy-pasting the following
+Create a new template into the ```` tag, copy-pasting the following
code.
.. code-block:: xml
@@ -348,7 +348,7 @@ target css rules to that element and avoid these affecting other content on the
.. warning::
Be careful replacing default elements attributes. As your theme will extend the default one,
- your changes will take priority in any future Odoo’s update.
+ your changes will take priority in any future Flectra’s update.
The second xpath will add a welcome message just after the navigation menu.
@@ -377,13 +377,13 @@ Imagine that we want to create a specific layout for a Services page.
For this page, we need to add a list of services to the top and give the client the possibility of setting the rest of the page’s layout using snippets.
Inside your *views* folder, create a **pages.xml** file and add the
-default Odoo markup. Inside ```` create a ```` tag, set the
+default Flectra markup. Inside ```` create a ```` tag, set the
``page`` attribute to ``True`` and add your code into it.
.. code-block:: xml
-
+
@@ -395,7 +395,7 @@ default Odoo markup. Inside ```` create a ```` tag, set the
-
+
The page title will be the template ID. In our case *Services* (from ``website.services``)
@@ -421,7 +421,7 @@ html code into a ```` tag, like in this example.
-Using ```` we will extend the Odoo
+Using ```` we will extend the Flectra
default page layout with our code.
As you can see, we wrapped our code into two ``
``, one with ID ``wrap`` and the other one with class ``container``. This is to provide a minimal layout.
@@ -433,7 +433,7 @@ can fill with snippets. To achieve this, just create a ``div`` with
.. code-block:: xml
-
+
@@ -453,7 +453,7 @@ can fill with snippets. To achieve this, just create a ``div`` with
-
+
.. tip::
@@ -506,7 +506,7 @@ If, for example, you want to place your link in the **middle**, you can set your
Add Styles
==========
-Odoo includes Bootstrap by default. This means that you can take advantage of all Bootstrap styles and layout functionalities out of the box.
+Flectra includes Bootstrap by default. This means that you can take advantage of all Bootstrap styles and layout functionalities out of the box.
Of course Bootstrap is not enough if you want to provide a unique design. The following steps will guide you through how to add custom styles to your theme.
The final result won't be pretty, but will provide you with enough information to build upon on your own.
@@ -538,7 +538,7 @@ The following rules will style our *Services* page. Copy and paste it, then save
Our file is ready but it is not included in our theme yet.
-Let’s navigate to the view folder and create an XML file called *assets.xml*. Add the default Odoo xml markup and copy/paste the following code. Remember to replace ``theme folder`` with your theme’s main folder name.
+Let’s navigate to the view folder and create an XML file called *assets.xml*. Add the default Flectra xml markup and copy/paste the following code. Remember to replace ``theme folder`` with your theme’s main folder name.
.. code-block:: xml
@@ -550,7 +550,7 @@ Let’s navigate to the view folder and create an XML file called *assets.xml*.
We just created a template specifying our less file. As you can see,
our template has a special attribute called ``inherit_id``. This
-attribute tells Odoo that our template is referring to another one in
+attribute tells Flectra that our template is referring to another one in
order to operate.
In this case, we are referring to ``assets_frontend`` template,
@@ -573,7 +573,7 @@ Update your theme
.. image:: theme_tutorial_assets/img/restart.png
-Our less file is now included in our theme, it will be automatically compiled, minified and combined with all Odoo’s assets.
+Our less file is now included in our theme, it will be automatically compiled, minified and combined with all Flectra’s assets.
.. image:: theme_tutorial_assets/img/services_page_styled.png
:class: shadow-0
@@ -584,7 +584,7 @@ Create Snippets
Since snippets are how users design and layout pages, they are the most important element of your design.
Let’s create a snippet for our Service page. The snippet will display three testimonials and it will be editable by the end user using the Website Builder UI.
Navigate to the view folder and create an XML file called **snippets.xml**.
-Add the default Odoo xml markup and copy/paste the following code.
+Add the default Flectra xml markup and copy/paste the following code.
The template contains the HTML markup that will be displayed by the snippet.
.. code-block:: xml
@@ -687,7 +687,7 @@ Options apply standard CSS classes to the snippet. Depending on the method that
Let's demonstrate how default options work with a basic example.
-We start by adding a new file in our views folder - name it **options.xml** and add the default Odoo XML markup. Create a new template copy/pasting the following
+We start by adding a new file in our views folder - name it **options.xml** and add the default Flectra XML markup. Create a new template copy/pasting the following
.. code-block:: xml
@@ -793,8 +793,8 @@ the following code
(function() {
'use strict';
- var website = odoo.website;
- website.odoo_website = {};
+ var website = flectra.website;
+ website.flectra_website = {};
})();
Great, we successfully created our javascript editor file. This file will contain all the javascript functions used by our snippets in edit mode. Let’s create a new function for our testimonial snippet using the ``snippet_testimonial_options`` method that we created before.
@@ -803,8 +803,8 @@ Great, we successfully created our javascript editor file. This file will contai
(function() {
'use strict';
- var website = odoo.website;
- website.odoo_website = {};
+ var website = flectra.website;
+ website.flectra_website = {};
website.snippet.options.snippet_testimonial_options = website.snippet.Option.extend({
onFocus: function() {
diff --git a/doc/howtos/web.rst b/doc/howtos/web.rst
index 10fb7971..91190b1b 100644
--- a/doc/howtos/web.rst
+++ b/doc/howtos/web.rst
@@ -8,10 +8,10 @@ Building Interface Extensions
.. default-domain:: js
-This guide is about creating modules for Odoo's web client.
+This guide is about creating modules for Flectra's web client.
-To create websites with Odoo, see :doc:`website`; to add business capabilities
-or extend existing business systems of Odoo, see :doc:`backend`.
+To create websites with Flectra, see :doc:`website`; to add business capabilities
+or extend existing business systems of Flectra, see :doc:`backend`.
.. warning::
@@ -21,13 +21,13 @@ or extend existing business systems of Odoo, see :doc:`backend`.
* jQuery_
* `Underscore.js`_
- It also requires :ref:`an installed Odoo `, and Git_.
+ It also requires :ref:`an installed Flectra `, and Git_.
A Simple Module
===============
-Let's start with a simple Odoo module holding basic web component
+Let's start with a simple Flectra module holding basic web component
configuration and letting us test the web framework.
The example module is available online and can be downloaded using the
@@ -35,11 +35,11 @@ following command:
.. code-block:: console
- $ git clone http://github.com/odoo/petstore
+ $ git clone http://github.com/flectra/petstore
This will create a ``petstore`` folder wherever you executed the command.
-You then need to add that folder to Odoo's
-:option:`addons path `, create a new database and
+You then need to add that folder to Flectra's
+:option:`addons path `, create a new database and
install the ``oepetstore`` module.
If you browse the ``petstore`` folder, you should see the following content:
@@ -72,7 +72,7 @@ The module already holds various server customizations. We'll come back to
these later, for now let's focus on the web-related content, in the ``static``
folder.
-Files used in the "web" side of an Odoo module must be placed in a ``static``
+Files used in the "web" side of an Flectra module must be placed in a ``static``
folder so they are available to a web browser, files outside that folder can
not be fetched by browsers. The ``src/css``, ``src/js`` and ``src/xml``
sub-folders are conventional and not strictly necessary.
@@ -86,7 +86,7 @@ sub-folders are conventional and not strictly necessary.
application (or at least its web-browser side) as javascript. It should
currently look like::
- odoo.oepetstore = function(instance, local) {
+ flectra.oepetstore = function(instance, local) {
var _t = instance.web._t,
_lt = instance.web._lt;
var QWeb = instance.web.qweb;
@@ -113,12 +113,12 @@ The files in the ``static`` folder, need to be defined within the module in orde
One of the drawback is debugging becomes more difficult as
individual files disappear and the code is made significantly less
readable. It is possible to disable this process by enabling the
- "developer mode": log into your Odoo instance (user *admin* password
+ "developer mode": log into your Flectra instance (user *admin* password
*admin* by default) open the user menu (in the top-right corner of the
- Odoo screen) and select :guilabel:`About Odoo` then :guilabel:`Activate
+ Flectra screen) and select :guilabel:`About Flectra` then :guilabel:`Activate
the developer mode`:
- .. image:: web/about_odoo.png
+ .. image:: web/about_flectra.png
:align: center
.. image:: web/devmode.png
@@ -129,7 +129,7 @@ The files in the ``static`` folder, need to be defined within the module in orde
.. todo:: qweb files hooked via __manifest__.py, but js and CSS use bundles
-Odoo JavaScript Module
+Flectra JavaScript Module
======================
Javascript doesn't have built-in modules. As a result variables defined in
@@ -137,29 +137,29 @@ different files are all mashed together and may conflict. This has given rise
to various module patterns used to build clean namespaces and limit risks of
naming conflicts.
-The Odoo framework uses one such pattern to define modules within web addons,
+The Flectra framework uses one such pattern to define modules within web addons,
in order to both namespace code and correctly order its loading.
``oepetstore/static/js/petstore.js`` contains a module declaration::
- odoo.oepetstore = function(instance, local) {
+ flectra.oepetstore = function(instance, local) {
local.xxx = ...;
}
-In Odoo web, modules are declared as functions set on the global ``odoo``
+In Flectra web, modules are declared as functions set on the global ``flectra``
variable. The function's name must be the same as the addon (in this case
``oepetstore``) so the framework can find it, and automatically initialize it.
When the web client loads your module it will call the root function
and provide two parameters:
-* the first parameter is the current instance of the Odoo web client, it gives
- access to various capabilities defined by the Odoo (translations,
+* the first parameter is the current instance of the Flectra web client, it gives
+ access to various capabilities defined by the Flectra (translations,
network services) as well as objects defined by the core or by other
modules.
* the second parameter is your own local namespace automatically created by
the web client. Objects and variables which should be accessible from
- outside your module (either because the Odoo web client needs to call them
+ outside your module (either because the Flectra web client needs to call them
or because others may want to customize them) should be set inside that
namespace.
@@ -170,11 +170,11 @@ Much as modules, and contrary to most object-oriented languages, javascript
does not build in *classes*\ [#classes]_ although it provides roughly
equivalent (if lower-level and more verbose) mechanisms.
-For simplicity and developer-friendliness Odoo web provides a class
+For simplicity and developer-friendliness Flectra web provides a class
system based on John Resig's `Simple JavaScript Inheritance`_.
-New classes are defined by calling the :func:`~odoo.web.Class.extend`
-method of :class:`odoo.web.Class`::
+New classes are defined by calling the :func:`~flectra.web.Class.extend`
+method of :class:`flectra.web.Class`::
var MyClass = instance.web.Class.extend({
say_hello: function() {
@@ -182,7 +182,7 @@ method of :class:`odoo.web.Class`::
},
});
-The :func:`~odoo.web.Class.extend` method takes a dictionary describing
+The :func:`~flectra.web.Class.extend` method takes a dictionary describing
the new class's content (methods and static attributes). In this case, it will
only have a ``say_hello`` method which takes no parameters.
@@ -223,8 +223,8 @@ parameters passed when using the ``new`` operator::
// print "hello Bob" in the console
It is also possible to create subclasses from existing (used-defined) classes
-by calling :func:`~odoo.web.Class.extend` on the parent class, as is done
-to subclass :class:`~odoo.web.Class`::
+by calling :func:`~flectra.web.Class.extend` on the parent class, as is done
+to subclass :class:`~flectra.web.Class`::
var MySpanishClass = MyClass.extend({
say_hello: function() {
@@ -277,14 +277,14 @@ call the original method::
Widgets Basics
==============
-The Odoo web client bundles jQuery_ for easy DOM manipulation. It is useful
+The Flectra web client bundles jQuery_ for easy DOM manipulation. It is useful
and provides a better API than standard `W3C DOM`_\ [#dombugs]_, but
insufficient to structure complex applications leading to difficult
maintenance.
Much like object-oriented desktop UI toolkits (e.g. Qt_, Cocoa_ or GTK_),
-Odoo Web makes specific components responsible for sections of a page. In
-Odoo web, the base for such components is the :class:`~odoo.Widget`
+Flectra Web makes specific components responsible for sections of a page. In
+Flectra web, the base for such components is the :class:`~flectra.Widget`
class, a component specialized in handling a page section and displaying
information for the user.
@@ -299,8 +299,8 @@ The initial demonstration module already provides a basic widget::
},
});
-It extends :class:`~odoo.Widget` and overrides the standard method
-:func:`~odoo.Widget.start`, which — much like the previous ``MyClass``
+It extends :class:`~flectra.Widget` and overrides the standard method
+:func:`~flectra.Widget.start`, which — much like the previous ``MyClass``
— does little for now.
This line at the end of the file::
@@ -327,14 +327,14 @@ Widgets have a number of methods and features, but the basics are simple:
* format the widget's data
* display the widget
-The ``HomePage`` widget already has a :func:`~odoo.Widget.start`
+The ``HomePage`` widget already has a :func:`~flectra.Widget.start`
method. That method is part of the normal widget lifecycle and automatically
called once the widget is inserted in the page. We can use it to display some
content.
-All widgets have a :attr:`~odoo.Widget.$el` which represents the
+All widgets have a :attr:`~flectra.Widget.$el` which represents the
section of page they're in charge of (as a jQuery_ object). Widget content
-should be inserted there. By default, :attr:`~odoo.Widget.$el` is an
+should be inserted there. By default, :attr:`~flectra.Widget.$el` is an
empty ``
`` element.
A ``
`` element is usually invisible to the user if it has no content (or
@@ -345,7 +345,7 @@ Let's add some content to the widget's root element, using jQuery::
local.HomePage = instance.Widget.extend({
start: function() {
- this.$el.append("
Hello dear Odoo user!
");
+ this.$el.append("
Hello dear Flectra user!
");
},
});
@@ -354,10 +354,10 @@ That message will now appear when you open :menuselection:`Pet Store
.. note::
- to refresh the javascript code loaded in Odoo Web, you will need to reload
- the page. There is no need to restart the Odoo server.
+ to refresh the javascript code loaded in Flectra Web, you will need to reload
+ the page. There is no need to restart the Flectra server.
-The ``HomePage`` widget is used by Odoo Web and managed automatically.
+The ``HomePage`` widget is used by Flectra Web and managed automatically.
To learn how to use a widget "from scratch" let's create a new one::
local.GreetingsWidget = instance.Widget.extend({
@@ -367,11 +367,11 @@ To learn how to use a widget "from scratch" let's create a new one::
});
We can now add our ``GreetingsWidget`` to the ``HomePage`` by using the
-``GreetingsWidget``'s :func:`~odoo.Widget.appendTo` method::
+``GreetingsWidget``'s :func:`~flectra.Widget.appendTo` method::
local.HomePage = instance.Widget.extend({
start: function() {
- this.$el.append("
Hello dear Odoo user!
");
+ this.$el.append("
Hello dear Flectra user!
");
var greeting = new local.GreetingsWidget(this);
return greeting.appendTo(this.$el);
},
@@ -380,17 +380,17 @@ We can now add our ``GreetingsWidget`` to the ``HomePage`` by using the
* ``HomePage`` first adds its own content to its DOM root
* ``HomePage`` then instantiates ``GreetingsWidget``
* Finally it tells ``GreetingsWidget`` where to insert itself, delegating part
- of its :attr:`~odoo.Widget.$el` to the ``GreetingsWidget``.
+ of its :attr:`~flectra.Widget.$el` to the ``GreetingsWidget``.
-When the :func:`~odoo.Widget.appendTo` method is called, it asks the
+When the :func:`~flectra.Widget.appendTo` method is called, it asks the
widget to insert itself at the specified position and to display its content.
-The :func:`~odoo.Widget.start` method will be called during the call
-to :func:`~odoo.Widget.appendTo`.
+The :func:`~flectra.Widget.start` method will be called during the call
+to :func:`~flectra.Widget.appendTo`.
To see what happens under the displayed interface, we will use the browser's
DOM Explorer. But first let's alter our widgets slightly so we can more easily
find where they are, by :attr:`adding a class to their root elements
-`::
+`::
local.HomePage = instance.Widget.extend({
className: 'oe_petstore_homepage',
@@ -407,14 +407,14 @@ then :guilabel:`Inspect Element`), it should look like this:
.. code-block:: html
-
Hello dear Odoo user!
+
Hello dear Flectra user!
We are so happy to see you again in this menu!
Which clearly shows the two ``
`` elements automatically created by
-:class:`~odoo.Widget`, because we added some classes on them.
+:class:`~flectra.Widget`, because we added some classes on them.
We can also see the two message-holding divs we added ourselves
@@ -442,7 +442,7 @@ of another widget, and exist on behalf of it. We call the container the
Due to multiple technical and conceptual reasons, it is necessary for a widget
to know who is its parent and who are its children.
-:func:`~odoo.Widget.getParent`
+:func:`~flectra.Widget.getParent`
can be used to get the parent of a widget::
local.GreetingsWidget = instance.Widget.extend({
@@ -452,7 +452,7 @@ to know who is its parent and who are its children.
},
});
-:func:`~odoo.Widget.getChildren`
+:func:`~flectra.Widget.getChildren`
can be used to get a list of its children::
local.HomePage = instance.Widget.extend({
@@ -464,7 +464,7 @@ to know who is its parent and who are its children.
},
});
-When overriding the :func:`~odoo.Widget.init` method of a widget it is
+When overriding the :func:`~flectra.Widget.init` method of a widget it is
*of the utmost importance* to pass the parent to the ``this._super()`` call,
otherwise the relation will not be set up correctly::
@@ -484,20 +484,20 @@ Destroying Widgets
------------------
If you can display content to your users, you should also be able to erase
-it. This is done via the :func:`~odoo.Widget.destroy` method::
+it. This is done via the :func:`~flectra.Widget.destroy` method::
greeting.destroy();
When a widget is destroyed it will first call
-:func:`~odoo.Widget.destroy` on all its children. Then it erases itself
+:func:`~flectra.Widget.destroy` on all its children. Then it erases itself
from the DOM. If you have set up permanent structures in
-:func:`~odoo.Widget.init` or :func:`~odoo.Widget.start` which
+:func:`~flectra.Widget.init` or :func:`~flectra.Widget.start` which
must be explicitly cleaned up (because the garbage collector will not handle
-them), you can override :func:`~odoo.Widget.destroy`.
+them), you can override :func:`~flectra.Widget.destroy`.
.. danger::
- when overriding :func:`~odoo.Widget.destroy`, ``_super()``
+ when overriding :func:`~flectra.Widget.destroy`, ``_super()``
*must always* be called otherwise the widget and its children are not
correctly cleaned up leaving possible memory leaks and "phantom events",
even if no error is displayed
@@ -508,14 +508,14 @@ The QWeb Template Engine
In the previous section we added content to our widgets by directly
manipulating (and adding to) their DOM::
- this.$el.append("
Hello dear Odoo user!
");
+ this.$el.append("
Hello dear Flectra user!
");
This allows generating and displaying any type of content, but gets unwieldy
when generating significant amounts of DOM (lots of duplication, quoting
issues, ...)
-As many other environments, Odoo's solution is to use a `template engine`_.
-Odoo's template engine is called :ref:`reference/qweb`.
+As many other environments, Flectra's solution is to use a `template engine`_.
+Flectra's template engine is called :ref:`reference/qweb`.
QWeb is an XML-based templating language, similar to `Genshi
`_, `Thymeleaf
@@ -525,21 +525,21 @@ characteristics:
* It's implemented fully in JavaScript and rendered in the browser
* Each template file (XML files) contains multiple templates
-* It has special support in Odoo Web's :class:`~odoo.Widget`, though it
- can be used outside of Odoo's web client (and it's possible to use
- :class:`~odoo.Widget` without relying on QWeb)
+* It has special support in Flectra Web's :class:`~flectra.Widget`, though it
+ can be used outside of Flectra's web client (and it's possible to use
+ :class:`~flectra.Widget` without relying on QWeb)
.. note::
The rationale behind using QWeb instead of existing javascript template
engines is the extensibility of pre-existing (third-party) templates, much
- like Odoo :ref:`views `.
+ like Flectra :ref:`views `.
Most javascript template engines are text-based which precludes easy
structural extensibility where an XML-based templating engine can be
generically altered using e.g. XPath or CSS and a tree-alteration DSL (or
even just XSLT). This flexibility and extensibility is a core
- characteristic of Odoo, and losing it was considered unacceptable.
+ characteristic of Flectra, and losing it was considered unacceptable.
Using QWeb
----------
@@ -569,9 +569,9 @@ template defined in the XML file::
:func:`QWeb.render` looks for the specified template, renders it to a string
and returns the result.
-However, because :class:`~odoo.Widget` has special integration for QWeb
+However, because :class:`~flectra.Widget` has special integration for QWeb
the template can be set directly on the widget via its
-:attr:`~odoo.Widget.template` attribute::
+:attr:`~flectra.Widget.template` attribute::
local.HomePage = instance.Widget.extend({
template: "HomePageTemplate",
@@ -584,7 +584,7 @@ Although the result looks similar, there are two differences between these
usages:
* with the second version, the template is rendered right before
- :func:`~odoo.Widget.start` is called
+ :func:`~flectra.Widget.start` is called
* in the first version the template's content is added to the widget's root
element, whereas in the second version the template's root element is
directly *set as* the widget's root element. Which is why the "greetings"
@@ -593,7 +593,7 @@ usages:
.. warning::
templates should have a single non-``t`` root element, especially if
- they're set as a widget's :attr:`~odoo.Widget.template`. If there are
+ they're set as a widget's :attr:`~flectra.Widget.template`. If there are
multiple "root elements", results are undefined (usually only the first
root element will be used and the others will be ignored)
@@ -621,11 +621,11 @@ will result in:
Hello Klaus
-When using :class:`~odoo.Widget`'s integration it is not possible to
+When using :class:`~flectra.Widget`'s integration it is not possible to
provide additional data to the template. The template will be given a single
``widget`` context variable, referencing the widget being rendered right
-before :func:`~odoo.Widget.start` is called (the widget's state will
-essentially be that set up by :func:`~odoo.Widget.init`):
+before :func:`~flectra.Widget.start` is called (the widget's state will
+essentially be that set up by :func:`~flectra.Widget.init`):
.. code-block:: xml
@@ -850,7 +850,7 @@ Exercise
::
- odoo.oepetstore = function(instance, local) {
+ flectra.oepetstore = function(instance, local) {
var _t = instance.web._t,
_lt = instance.web._lt;
var QWeb = instance.web.qweb;
@@ -918,8 +918,8 @@ Selecting DOM elements within a widget can be performed by calling the
this.$el.find("input.my_input")...
-But because it's a common operation, :class:`~odoo.Widget` provides an
-equivalent shortcut through the :func:`~odoo.Widget.$` method::
+But because it's a common operation, :class:`~flectra.Widget` provides an
+equivalent shortcut through the :func:`~flectra.Widget.$` method::
local.MyWidget = instance.Widget.extend({
start: function() {
@@ -963,7 +963,7 @@ While this works it has a few issues:
3. it requires dealing with ``this``-binding issues
Widgets thus provide a shortcut to DOM event binding via
-:attr:`~odoo.Widget.events`::
+:attr:`~flectra.Widget.events`::
local.MyWidget = instance.Widget.extend({
events: {
@@ -974,7 +974,7 @@ Widgets thus provide a shortcut to DOM event binding via
}
});
-:attr:`~odoo.Widget.events` is an object (mapping) of an event to the
+:attr:`~flectra.Widget.events` is an object (mapping) of an event to the
function or method to call when the event is triggered:
* the key is an event name, possibly refined with a CSS selector in which
@@ -1025,12 +1025,12 @@ This widget acts as a facade, transforming user input (through DOM events)
into a documentable internal event to which parent widgets can bind
themselves.
-:func:`~odoo.Widget.trigger` takes the name of the event to trigger as
+:func:`~flectra.Widget.trigger` takes the name of the event to trigger as
its first (mandatory) argument, any further arguments are treated as event
data and passed directly to listeners.
We can then set up a parent event instantiating our generic widget and
-listening to the ``user_chose`` event using :func:`~odoo.Widget.on`::
+listening to the ``user_chose`` event using :func:`~flectra.Widget.on`::
local.HomePage = instance.Widget.extend({
start: function() {
@@ -1047,11 +1047,11 @@ listening to the ``user_chose`` event using :func:`~odoo.Widget.on`::
},
});
-:func:`~odoo.Widget.on` binds a function to be called when the
+:func:`~flectra.Widget.on` binds a function to be called when the
event identified by ``event_name`` is. The ``func`` argument is the
function to call and ``object`` is the object to which that function is
related if it is a method. The bound function will be called with the
-additional arguments of :func:`~odoo.Widget.trigger` if it has
+additional arguments of :func:`~flectra.Widget.trigger` if it has
any. Example::
start: function() {
@@ -1067,9 +1067,9 @@ any. Example::
.. note::
Triggering events on an other widget is generally a bad idea. The main
- exception to that rule is ``odoo.web.bus`` which exists specifically
+ exception to that rule is ``flectra.web.bus`` which exists specifically
to broadcasts evens in which any widget could be interested throughout
- the Odoo web application.
+ the Flectra web application.
Properties
----------
@@ -1087,10 +1087,10 @@ that they trigger events when set::
console.log("The new value of the property 'name' is", this.widget.get("name"));
}
-* :func:`~odoo.Widget.set` sets the value of a property and triggers
+* :func:`~flectra.Widget.set` sets the value of a property and triggers
:samp:`change:{propname}` (where *propname* is the property name passed as
- first parameter to :func:`~odoo.Widget.set`) and ``change``
-* :func:`~odoo.Widget.get` retrieves the value of a property.
+ first parameter to :func:`~flectra.Widget.set`) and ``change``
+* :func:`~flectra.Widget.get` retrieves the value of a property.
Exercise
--------
@@ -1119,7 +1119,7 @@ Exercise
::
- odoo.oepetstore = function(instance, local) {
+ flectra.oepetstore = function(instance, local) {
var _t = instance.web._t,
_lt = instance.web._lt;
var QWeb = instance.web.qweb;
@@ -1188,8 +1188,8 @@ Exercise
Modify existing widgets and classes
===================================
-The class system of the Odoo web framework allows direct modification of
-existing classes using the :func:`~odoo.web.Class.include` method::
+The class system of the Flectra web framework allows direct modification of
+existing classes using the :func:`~flectra.web.Class.include` method::
var TestClass = instance.web.Class.extend({
testMethod: function() {
@@ -1212,9 +1212,9 @@ target class in-place instead of creating a new class.
In that case, ``this._super()`` will call the original implementation of a
method being replaced/redefined. If the class already had sub-classes, all
calls to ``this._super()`` in sub-classes will call the new implementations
-defined in the call to :func:`~odoo.web.Class.include`. This will also work
+defined in the call to :func:`~flectra.web.Class.include`. This will also work
if some instances of the class (or of any of its sub-classes) were created
-prior to the call to :func:`~odoo.Widget.include`.
+prior to the call to :func:`~flectra.Widget.include`.
Translations
============
@@ -1231,11 +1231,11 @@ JavaScript module. They are used thus::
this.$el.text(_t("Hello user!"));
-In Odoo, translations files are automatically generated by scanning the source
+In Flectra, translations files are automatically generated by scanning the source
code. All piece of code that calls a certain function are detected and their
content is added to a translation file that will then be sent to the
translators. In Python, the function is ``_()``. In JavaScript the function is
-:func:`~odoo.web._t` (and also :func:`~odoo.web._lt`).
+:func:`~flectra.web._t` (and also :func:`~flectra.web._lt`).
``_t()`` will return the translation defined for the text it is given. If no
translation is defined for that text, it will return the original text as-is.
@@ -1255,7 +1255,7 @@ translation is defined for that text, it will return the original text as-is.
This makes translatable strings more readable to translators, and gives
them more flexibility to reorder or ignore parameters.
-:func:`~odoo.web._lt` ("lazy translate") is similar but somewhat more
+:func:`~flectra.web._lt` ("lazy translate") is similar but somewhat more
complex: instead of translating its parameter immediately, it returns
an object which, when converted to a string, will perform the translation.
@@ -1263,19 +1263,19 @@ It is used to define translatable terms before the translations system is
initialized, for class attributes for instance (as modules are loaded before
the user's language is configured and translations are downloaded).
-Communication with the Odoo Server
+Communication with the Flectra Server
==================================
Contacting Models
-----------------
-Most operations with Odoo involve communicating with *models* implementing
+Most operations with Flectra involve communicating with *models* implementing
business concern, these models will then (potentially) interact with some
storage engine (usually PostgreSQL_).
Although jQuery_ provides a `$.ajax`_ function for network interactions,
-communicating with Odoo requires additional metadata whose setup before every
-call would be verbose and error-prone. As a result, Odoo web provides
+communicating with Flectra requires additional metadata whose setup before every
+call would be verbose and error-prone. As a result, Flectra web provides
higher-level communication primitives.
To demonstrate this, the file ``petstore.py`` already contains a small model
@@ -1309,12 +1309,12 @@ Here is a sample widget that calls ``my_method()`` and displays the result::
},
});
-The class used to call Odoo models is :class:`odoo.Model`. It is
-instantiated with the Odoo model's name as first parameter
+The class used to call Flectra models is :class:`flectra.Model`. It is
+instantiated with the Flectra model's name as first parameter
(``oepetstore.message_of_the_day`` here).
-:func:`~odoo.web.Model.call` can be used to call any (public) method of an
-Odoo model. It takes the following positional arguments:
+:func:`~flectra.web.Model.call` can be used to call any (public) method of an
+Flectra model. It takes the following positional arguments:
``name``
The name of the method to call, ``my_method`` here
@@ -1349,7 +1349,7 @@ Odoo model. It takes the following positional arguments:
model.call("my_method", [], {a: 1, b: 2, c: 3, ...
// with this a=1, b=2 and c=3
-:func:`~odoo.Widget.call` returns a deferred resolved with the value
+:func:`~flectra.Widget.call` returns a deferred resolved with the value
returned by the model's method as first argument.
CompoundContext
@@ -1364,19 +1364,19 @@ The context is like a "magic" argument that the web client will always give to
the server when calling a method. The context is a dictionary containing
multiple keys. One of the most important key is the language of the user, used
by the server to translate all the messages of the application. Another one is
-the time zone of the user, used to compute correctly dates and times if Odoo
+the time zone of the user, used to compute correctly dates and times if Flectra
is used by people in different countries.
The ``argument`` is necessary in all methods, otherwise bad things could
happen (such as the application not being translated correctly). That's why,
when you call a model's method, you should always provide that argument. The
-solution to achieve that is to use :class:`odoo.web.CompoundContext`.
+solution to achieve that is to use :class:`flectra.web.CompoundContext`.
-:class:`~odoo.web.CompoundContext` is a class used to pass the user's
+:class:`~flectra.web.CompoundContext` is a class used to pass the user's
context (with language, time zone, etc...) to the server as well as adding new
keys to the context (some models' methods use arbitrary keys added to the
context). It is created by giving to its constructor any number of
-dictionaries or other :class:`~odoo.web.CompoundContext` instances. It will
+dictionaries or other :class:`~flectra.web.CompoundContext` instances. It will
merge all those contexts before sending them to the server.
.. code-block:: javascript
@@ -1391,19 +1391,19 @@ merge all those contexts before sending them to the server.
// will print: {'lang': 'en_US', 'new_key': 'key_value', 'tz': 'Europe/Brussels', 'uid': 1}
You can see the dictionary in the argument ``context`` contains some keys that
-are related to the configuration of the current user in Odoo plus the
+are related to the configuration of the current user in Flectra plus the
``new_key`` key that was added when instantiating
-:class:`~odoo.web.CompoundContext`.
+:class:`~flectra.web.CompoundContext`.
Queries
-------
-While :func:`~odoo.Model.call` is sufficient for any interaction with Odoo
-models, Odoo Web provides a helper for simpler and clearer querying of models
+While :func:`~flectra.Model.call` is sufficient for any interaction with Flectra
+models, Flectra Web provides a helper for simpler and clearer querying of models
(fetching of records based on various conditions):
-:func:`~odoo.Model.query` which acts as a shortcut for the common
-combination of :py:meth:`~odoo.models.Model.search` and
-::py:meth:`~odoo.models.Model.read`. It provides a clearer syntax to search
+:func:`~flectra.Model.query` which acts as a shortcut for the common
+combination of :py:meth:`~flectra.models.Model.search` and
+::py:meth:`~flectra.models.Model.read`. It provides a clearer syntax to search
and read models::
model.query(['name', 'login', 'user_email', 'signature'])
@@ -1423,19 +1423,19 @@ versus::
// do work with users records
});
-* :func:`~odoo.web.Model.query` takes an optional list of fields as
+* :func:`~flectra.web.Model.query` takes an optional list of fields as
parameter (if no field is provided, all fields of the model are fetched). It
- returns a :class:`odoo.web.Query` which can be further customized before
+ returns a :class:`flectra.web.Query` which can be further customized before
being executed
-* :class:`~odoo.web.Query` represents the query being built. It is
+* :class:`~flectra.web.Query` represents the query being built. It is
immutable, methods to customize the query actually return a modified copy,
so it's possible to use the original and the new version side-by-side. See
- :class:`~odoo.web.Query` for its customization options.
+ :class:`~flectra.web.Query` for its customization options.
When the query is set up as desired, simply call
-:func:`~odoo.web.Query.all` to execute it and return a
+:func:`~flectra.web.Query.all` to execute it and return a
deferred to its result. The result is the same as
-:py:meth:`~odoo.models.Model.read`'s, an array of dictionaries where each
+:py:meth:`~flectra.models.Model.read`'s, an array of dictionaries where each
dictionary is a requested record, with each requested field a dictionary key.
Exercises
@@ -1453,7 +1453,7 @@ Exercises
.. code-block:: javascript
- odoo.oepetstore = function(instance, local) {
+ flectra.oepetstore = function(instance, local) {
var _t = instance.web._t,
_lt = instance.web._lt;
var QWeb = instance.web.qweb;
@@ -1519,7 +1519,7 @@ Exercises
need to explore ``product.product`` to create the right domain to
select just pet toys.
- In Odoo, images are generally stored in regular fields encoded as
+ In Flectra, images are generally stored in regular fields encoded as
base64_, HTML supports displaying images straight from base64 with
:samp:``
@@ -1531,7 +1531,7 @@ Exercises
.. code-block:: javascript
- odoo.oepetstore = function(instance, local) {
+ flectra.oepetstore = function(instance, local) {
var _t = instance.web._t,
_lt = instance.web._lt;
var QWeb = instance.web.qweb;
@@ -1648,7 +1648,7 @@ Existing web components
The Action Manager
------------------
-In Odoo, many operations start from an :ref:`action `:
+In Flectra, many operations start from an :ref:`action `:
opening a menu item (to a view), printing a report, ...
Actions are pieces of data describing how a client should react to the
@@ -1656,7 +1656,7 @@ activation of a piece of content. Actions can be stored (and read through a
model) or they can be generated on-the fly (locally to the client by
javascript code, or remotely by a method of a model).
-In Odoo Web, the component responsible for handling and reacting to these
+In Flectra Web, the component responsible for handling and reacting to these
actions is the *Action Manager*.
Using the Action Manager
@@ -1666,7 +1666,7 @@ The action manager can be invoked explicitly from javascript code by creating
a dictionary describing :ref:`an action ` of the right
type, and calling an action manager instance with it.
-:func:`~odoo.Widget.do_action` is a shortcut of :class:`~odoo.Widget`
+:func:`~flectra.Widget.do_action` is a shortcut of :class:`~flectra.Widget`
looking up the "current" action manager and executing the action::
instance.web.TestWidget = instance.Widget.extend({
@@ -1753,11 +1753,11 @@ Client Actions
Throughout this guide, we used a simple ``HomePage`` widget which the web
client automatically starts when we select the right menu item. But how did
-the Odoo web know to start this widget? Because the widget is registered as
+the Flectra web know to start this widget? Because the widget is registered as
a *client action*.
A client action is (as its name implies) an action type defined almost
-entirely in the client, in javascript for Odoo web. The server simply sends
+entirely in the client, in javascript for Flectra web. The server simply sends
an action tag (an arbitrary name), and optionally adds a few parameters, but
beyond that *everything* is handled by custom client code.
@@ -1766,11 +1766,11 @@ Our widget is registered as the handler for the client action through this::
instance.web.client_actions.add('petstore.homepage', 'instance.oepetstore.HomePage');
-``instance.web.client_actions`` is a :class:`~odoo.web.Registry` in which
+``instance.web.client_actions`` is a :class:`~flectra.web.Registry` in which
the action manager looks up client action handlers when it needs to execute
-one. The first parameter of :class:`~odoo.web.Registry.add` is the name
+one. The first parameter of :class:`~flectra.web.Registry.add` is the name
(tag) of the client action, and the second parameter is the path to the widget
-from the Odoo web client root.
+from the Flectra web client root.
When a client action must be executed, the action manager looks up its tag
in the registry, walks the specified path and displays the widget it finds at
@@ -1798,7 +1798,7 @@ and a menu opening the action:
Architecture of the Views
-------------------------
-Much of Odoo web's usefulness (and complexity) resides in views. Each view
+Much of Flectra web's usefulness (and complexity) resides in views. Each view
type is a way of displaying a model in the client.
The View Manager
@@ -1816,26 +1816,26 @@ multiple views depending on the original action's requirements:
The Views
'''''''''
-Most :ref:`Odoo views ` are implemented through a subclass
-of :class:`odoo.web.View` which provides a bit of generic basic structure
+Most :ref:`Flectra views ` are implemented through a subclass
+of :class:`flectra.web.View` which provides a bit of generic basic structure
for handling events and displaying model information.
-The *search view* is considered a view type by the main Odoo framework, but
+The *search view* is considered a view type by the main Flectra framework, but
handled separately by the web client (as it's a more permanent fixture and
can interact with other views, which regular views don't do).
A view is responsible for loading its own description XML (using
-:py:class:`~odoo.models.Model.fields_view_get`) and any other data source
+:py:class:`~flectra.models.Model.fields_view_get`) and any other data source
it needs. To that purpose, views are provided with an optional view
-identifier set as the :attr:`~odoo.web.View.view_id` attribute.
+identifier set as the :attr:`~flectra.web.View.view_id` attribute.
-Views are also provided with a :class:`~odoo.web.DataSet` instance which
+Views are also provided with a :class:`~flectra.web.DataSet` instance which
holds most necessary model information (the model name and possibly various
record ids).
Views may also want to handle search queries by overriding
-:func:`~odoo.web.View.do_search`, and updating their
-:class:`~odoo.web.DataSet` as necessary.
+:func:`~flectra.web.View.do_search`, and updating their
+:class:`~flectra.web.DataSet` as necessary.
The Form View Fields
--------------------
@@ -1847,7 +1847,7 @@ All built-in fields have a default display implementation, a new
form widget may be necessary to correctly interact with a new field type
(e.g. a :term:`GIS` field) or to provide new representations and ways to
interact with existing field types (e.g. validate
-:py:class:`~odoo.fields.Char` fields which should contain email addresses
+:py:class:`~flectra.fields.Char` fields which should contain email addresses
and display them as email links).
To explicitly specify which form widget should be used to display a field,
@@ -1880,7 +1880,7 @@ Here are some of the responsibilities of a field class:
* The field class must display and allow the user to edit the value of the field.
* It must correctly implement the 3 field attributes available in all fields
- of Odoo. The ``AbstractField`` class already implements an algorithm that
+ of Flectra. The ``AbstractField`` class already implements an algorithm that
dynamically calculates the value of these attributes (they can change at any
moment because their value change according to the value of other
fields). Their values are stored in *Widget Properties* (the widget
@@ -1896,7 +1896,7 @@ Here are some of the responsibilities of a field class:
``AbstractField`` class already has a basic implementation of this
behavior that fits most fields.
* ``readonly``: When ``true``, the field must not be editable by the
- user. Most fields in Odoo have a completely different behavior depending
+ user. Most fields in Flectra have a completely different behavior depending
on the value of ``readonly``. As example, the ``FieldChar`` displays an
HTML ```` when it is editable and simply displays the text when
it is read-only. This also means it has much more code it would need to
@@ -1906,10 +1906,10 @@ Here are some of the responsibilities of a field class:
* Fields have two methods, ``set_value()`` and ``get_value()``, which are
called by the form view to give it the value to display and get back the new
value entered by the user. These methods must be able to handle the value as
- given by the Odoo server when a ``read()`` is performed on a model and give
+ given by the Flectra server when a ``read()`` is performed on a model and give
back a valid value for a ``write()``. Remember that the JavaScript/Python
data types used to represent the values given by ``read()`` and given to
- ``write()`` is not necessarily the same in Odoo. As example, when you read a
+ ``write()`` is not necessarily the same in Flectra. As example, when you read a
many2one, it is always a tuple whose first value is the id of the pointed
record and the second one is the name get (ie: ``(15, "Agrolait")``). But
when you write a many2one it must be a single integer, not a tuple
@@ -1919,7 +1919,7 @@ Here are some of the responsibilities of a field class:
Please note that, to better understand how to implement fields, you are
strongly encouraged to look at the definition of the ``FieldInterface``
-interface and the ``AbstractField`` class directly in the code of the Odoo web
+interface and the ``AbstractField`` class directly in the code of the Flectra web
client.
Creating a New Type of Field
@@ -1973,7 +1973,7 @@ Read-Write Field
""""""""""""""""
Read-only fields, which only display content and don't allow the
-user to modify it can be useful, but most fields in Odoo also allow editing.
+user to modify it can be useful, but most fields in Flectra also allow editing.
This makes the field classes more complicated, mostly because fields are
supposed to handle both editable and non-editable mode, those modes are
often completely different (for design and usability purpose) and the fields
@@ -2150,7 +2150,7 @@ abstract class.
Form widgets can interact with form fields by listening for their changes and
fetching or altering their values. They can access form fields through
-their :attr:`~odoo.web.form.FormWidget.field_manager` attribute::
+their :attr:`~flectra.web.form.FormWidget.field_manager` attribute::
local.WidgetMultiplication = instance.web.form.FormWidget.extend({
start: function() {
@@ -2168,14 +2168,14 @@ their :attr:`~odoo.web.form.FormWidget.field_manager` attribute::
instance.web.form.custom_widgets.add('multiplication', 'instance.oepetstore.WidgetMultiplication');
-:attr:`~odoo.web.form.FormWidget` is generally the
-:class:`~odoo.web.form.FormView` itself, but features used from it should
-be limited to those defined by :class:`~odoo.web.form.FieldManagerMixin`,
+:attr:`~flectra.web.form.FormWidget` is generally the
+:class:`~flectra.web.form.FormView` itself, but features used from it should
+be limited to those defined by :class:`~flectra.web.form.FieldManagerMixin`,
the most useful being:
-* :func:`~odoo.web.form.FieldManagerMixin.get_field_value(field_name)`
+* :func:`~flectra.web.form.FieldManagerMixin.get_field_value(field_name)`
which returns the value of a field.
-* :func:`~odoo.web.form.FieldManagerMixin.set_values(values)` sets multiple
+* :func:`~flectra.web.form.FieldManagerMixin.set_values(values)` sets multiple
field values, takes a mapping of ``{field_name: value_to_set}``
* An event :samp:`field_changed:{field_name}` is triggered any time the value
of the field called ``field_name`` is changed
diff --git a/doc/howtos/website.rst b/doc/howtos/website.rst
index 51450f40..dba55e21 100644
--- a/doc/howtos/website.rst
+++ b/doc/howtos/website.rst
@@ -10,23 +10,23 @@ Building a Website
* This guide assumes `basic knowledge of Python
`_
- * This guide assumes :ref:`an installed Odoo `
+ * This guide assumes :ref:`an installed Flectra `
Creating a basic module
=======================
-In Odoo, tasks are performed by creating modules.
+In Flectra, tasks are performed by creating modules.
-Modules customize the behavior of an Odoo installation, either by adding new
+Modules customize the behavior of an Flectra installation, either by adding new
behaviors or by altering existing ones (including behaviors added by other
modules).
-:ref:`Odoo's scaffolding ` can setup a basic
+:ref:`Flectra's scaffolding ` can setup a basic
module. To quickly get started simply invoke:
.. code-block:: console
- $ ./odoo-bin scaffold Academy my-modules
+ $ ./flectra-bin scaffold Academy my-modules
This will automatically create a ``my-modules`` *module directory* with an
``academy`` module inside. The directory can be an existing module directory
@@ -42,11 +42,11 @@ We have a "complete" module ready for installation.
Although it does absolutely nothing we can install it:
-* start the Odoo server
+* start the Flectra server
.. code-block:: console
- $ ./odoo-bin --addons-path addons,my-modules
+ $ ./flectra-bin --addons-path addons,my-modules
* go to http://localhost:8069
* create a new database including demonstration data
@@ -62,7 +62,7 @@ To the browser
send data back.
Add a simple controller and ensure it is imported by ``__init__.py`` (so
-Odoo can find it):
+Flectra can find it):
.. patch::
@@ -70,7 +70,7 @@ Shut down your server (:kbd:`^C`) then restart it:
.. code-block:: console
- $ ./odoo-bin --addons-path addons,my-modules
+ $ ./flectra-bin --addons-path addons,my-modules
and open a page to http://localhost:8069/academy/academy/, you should see your
"page" appear:
@@ -83,7 +83,7 @@ Templates
Generating HTML in Python isn't very pleasant.
The usual solution is templates_, pseudo-documents with placeholders and
-display logic. Odoo allows any Python templating system, but provides its
+display logic. Flectra allows any Python templating system, but provides its
own :ref:`QWeb ` templating system which integrates with other
features.
@@ -95,27 +95,27 @@ Create a template and ensure the template file is registered in the
The templates iterates (``t-foreach``) on all the teachers (passed through the
*template context*), and prints each teacher in its own paragraph.
-Finally restart Odoo and update the module's data (to install the template)
+Finally restart Flectra and update the module's data (to install the template)
by going to :menuselection:`Settings --> Modules --> Modules -->
Academy` and clicking :guilabel:`Upgrade`.
.. tip::
- Alternatively, Odoo can be restarted :option:`and update modules at
- the same time`:
+ Alternatively, Flectra can be restarted :option:`and update modules at
+ the same time`:
.. code-block:: console
- $ odoo-bin --addons-path addons,my-modules -d academy -u academy
+ $ flectra-bin --addons-path addons,my-modules -d academy -u academy
Going to http://localhost:8069/academy/academy/ should now result in:
.. image:: website/basic-list.png
-Storing data in Odoo
+Storing data in Flectra
====================
-:ref:`Odoo models ` map to database tables.
+:ref:`Flectra models ` map to database tables.
In the previous section we just displayed a list of string entered statically
in the Python code. This doesn't allow modifications or persistent storage
@@ -174,7 +174,7 @@ Accessing the data
The last step is to alter model and template to use our demonstration data:
#. fetch the records from the database instead of having a static list
-#. Because :meth:`~odoo.models.Model.search` returns a set of records
+#. Because :meth:`~flectra.models.Model.search` returns a set of records
matching the filter ("all records" here), alter the template to print each
teacher's ``name``
@@ -189,9 +189,9 @@ identifier for the teacher).
Website support
===============
-Odoo bundles a module dedicated to building websites.
+Flectra bundles a module dedicated to building websites.
-So far we've used controllers fairly directly, but Odoo 8 added deeper
+So far we've used controllers fairly directly, but Flectra 8 added deeper
integration and a few other services (e.g. default styling, theming) via the
``website`` module.
@@ -214,7 +214,7 @@ The website layout also provides support for edition tools: click
:guilabel:`Sign In` (in the top-right), fill the credentials in (``admin`` /
``admin`` by default) then click :guilabel:`Log In`.
-You're now in Odoo "proper": the administrative interface. For now click on
+You're now in Flectra "proper": the administrative interface. For now click on
the :guilabel:`Website` menu item (top-left corner.
We're back in the website but as an administrator, with access to advanced
@@ -231,7 +231,7 @@ URLs and routing
================
Controller methods are associated with *routes* via the
-:func:`~odoo.http.route` decorator which takes a routing string and a
+:func:`~flectra.http.route` decorator which takes a routing string and a
number of attributes to customise its behavior or security.
We've seen a "literal" routing string, which matches a URL section exactly,
@@ -241,7 +241,7 @@ create a new controller method which takes a bit of URL and prints it out:
.. patch::
-restart Odoo, access http://localhost:8069/academy/Alice/ and
+restart Flectra, access http://localhost:8069/academy/Alice/ and
http://localhost:8069/academy/Bob/ and see the difference.
As the name indicates, `converter patterns`_ don't just do extraction, they
@@ -250,13 +250,13 @@ to only accept integers:
.. patch::
-Restart Odoo, access http://localhost:8069/academy/2, note how the old value
+Restart Flectra, access http://localhost:8069/academy/2, note how the old value
was a string, but the new one was converted to an integers. Try accessing
http://localhost:8069/academy/Carol/ and note that the page was not found:
since "Carol" is not an integer, the route was ignored and no route could be
found.
-Odoo provides an additional converter called ``model`` which provides records
+Flectra provides an additional converter called ``model`` which provides records
directly when given their id. Let's use this to create a generic page for
teacher biographies:
@@ -266,7 +266,7 @@ then change the list of model to link to our new controller:
.. patch::
-Restart Odoo and upgrade the module, then you can visit each teacher's page.
+Restart Flectra and upgrade the module, then you can visit each teacher's page.
As an exercise, try adding blocks to a teacher's page to write a biography,
then go to another teacher's page and so forth. You will discover, that your
biography is shared between all teachers, because blocks are added to the
@@ -281,7 +281,7 @@ add a new biography field to our teachers:
.. patch::
-Restart Odoo and update the views, reload the teacher's page and… the field
+Restart Flectra and update the views, reload the teacher's page and… the field
is invisible since it contains nothing.
.. todo:: the view has been set to noupdate because modified previously,
@@ -293,7 +293,7 @@ interfaces. Change the *person* template to use ``t-field``:
.. patch::
-Restart Odoo and upgrade the module, there is now a placeholder under the
+Restart Flectra and upgrade the module, there is now a placeholder under the
teacher's name and a new zone for blocks in :guilabel:`Edit` mode. Content
dropped there is stored in the corresponding teacher's ``biography`` field, and
thus specific to that teacher.
@@ -318,28 +318,28 @@ or a relative display:
Administration and ERP integration
==================================
-A brief and incomplete introduction to the Odoo administration
+A brief and incomplete introduction to the Flectra administration
--------------------------------------------------------------
-The Odoo administration was briefly seen during the `website support`_ section.
+The Flectra administration was briefly seen during the `website support`_ section.
We can go back to it using :menuselection:`Administrator --> Administrator` in
the menu (or :guilabel:`Sign In` if you're signed out).
-The conceptual structure of the Odoo backend is simple:
+The conceptual structure of the Flectra backend is simple:
#. first are menus, a tree (menus can have sub-menus) of records. Menus
without children map to…
-#. actions. Actions have various types: links, reports, code which Odoo should
+#. actions. Actions have various types: links, reports, code which Flectra should
execute or data display. Data display actions are called *window actions*,
- and tell Odoo to display a given *model* according to a set of views…
+ and tell Flectra to display a given *model* according to a set of views…
#. a view has a type, a broad category to which it corresponds (a list,
a graph, a calendar) and an *architecture* which customises the way the
model is displayed inside the view.
-Editing in the Odoo administration
+Editing in the Flectra administration
----------------------------------
-By default, an Odoo model is essentially invisible to a user. To make it
+By default, an Flectra model is essentially invisible to a user. To make it
visible it must be available through an action, which itself needs to be
reachable, generally through a menu.
@@ -354,7 +354,7 @@ and having opened a listing of teachers. From the listing it is possible to
view.
If there is no definition of how to present records (a
-:ref:`view `) Odoo will automatically create a basic one
+:ref:`view `) Flectra will automatically create a basic one
on-the-fly. In our case it works for the "list" view for now (only displays
the teacher's name) but in the "form" view the HTML ``biography`` field is
displayed side-by-side with the ``name`` field and not given enough space.
@@ -384,7 +384,7 @@ let's also add views so we can see and edit a course's teacher:
It should also be possible to create new courses directly from a teacher's
page, or to see all the courses they teach, so add
-:class:`the inverse relationship ` to the *teachers*
+:class:`the inverse relationship ` to the *teachers*
model:
.. patch::
@@ -392,13 +392,13 @@ model:
Discussions and notifications
-----------------------------
-Odoo provides technical models, which don't directly fulfill business needs
+Flectra provides technical models, which don't directly fulfill business needs
but which add capabilities to business objects without having to build
them by hand.
-One of these is the *Chatter* system, part of Odoo's email and messaging
+One of these is the *Chatter* system, part of Flectra's email and messaging
system, which can add notifications and discussion threads to any model.
-The model simply has to :attr:`~odoo.models.Model._inherit`
+The model simply has to :attr:`~flectra.models.Model._inherit`
``mail.thread``, and add the ``message_ids`` field to its form view to display
the discussion thread. Discussion threads are per-record.
@@ -414,9 +414,9 @@ discussions linked to specific courses.
Selling courses
---------------
-Odoo also provides business models which allow using or opting in business
+Flectra also provides business models which allow using or opting in business
needs more directly. For instance the ``website_sale`` module sets up an
-e-commerce site based on the products in the Odoo system. We can easily make
+e-commerce site based on the products in the Flectra system. We can easily make
course subscriptions sellable by making our courses specific kinds of
products.
@@ -429,7 +429,7 @@ products (via ``sale``) and the ecommerce interface:
.. patch::
-restart Odoo, update your module, there is now a :guilabel:`Shop` section in
+restart Flectra, update your module, there is now a :guilabel:`Shop` section in
the website, listing a number of pre-filled (via demonstration data) products.
The second step is to replace the *courses* model by ``product.template``,
@@ -443,8 +443,8 @@ though they may have to be looked for.
.. note::
* to extend a model in-place, it's :attr:`inherited
- ` without giving it a new
- :attr:`~odoo.models.Model._name`
+ ` without giving it a new
+ :attr:`~flectra.models.Model._name`
* ``product.template`` already uses the discussions system, so we can
remove it from our extension model
* we're creating our courses as *published* by default so they can be
diff --git a/doc/python3.rst b/doc/python3.rst
index 88475d7d..0682baad 100644
--- a/doc/python3.rst
+++ b/doc/python3.rst
@@ -4,16 +4,16 @@
Python 3 compatibility/conversions
==================================
-Official compatibility: Odoo 11 will be the first LTS release to introduce
+Official compatibility: Flectra 11 will be the first LTS release to introduce
Python 3 compatibility, starting with Python 3.5. It will also be the first
LTS release to drop official support for Python 2.
Rationale: Python 3 has been around since 2008, and all Python libraries
-used by the official Odoo distribution have been ported and are considered
+used by the official Flectra distribution have been ported and are considered
stable. Most supported platforms have a Python 3.5 package, or a similar
way to deploy it. Preserving dual compatibility is therefore considered
unnecessary, and would represent a significant overhead in testing for the
-lifetime of Odoo 11.
+lifetime of Flectra 11.
Python 2 and Python 3 are somewhat different language, but following
backports, forward ports and cross-compatibility library it is possible to
@@ -26,9 +26,9 @@ with Python 3.
.. important::
This is not a general-purpose guide for porting Python 2 to Python 3, it's
- a guide to write 2/3-compatible Odoo code. It does not go through all the
+ a guide to write 2/3-compatible Flectra code. It does not go through all the
changes in Python but rather through issues which have been found in the
- standard Odoo distribution in order to show how to evolve such code such
+ standard Flectra distribution in order to show how to evolve such code such
that it works on both Python 2 and Python 3.
References/useful documents:
@@ -48,7 +48,7 @@ References/useful documents:
Versions Support
================
-A cross compatible Odoo would only support Python 2.7 and Python 3.5 and
+A cross compatible Flectra would only support Python 2.7 and Python 3.5 and
above: Python 2.7 backported some Python 3 features, and Python 2 features
were reintroduced in various Python 3 in order to make conversion easier.
Python 3.6 adds great features (f-strings, ...) and performance improvements
@@ -65,13 +65,13 @@ features whereas:
.. warning::
While Python 3 adds plenty of great features (keyword-only parameters,
- generator delegation, pathlib, ...), you must *not* use them in Odoo
+ generator delegation, pathlib, ...), you must *not* use them in Flectra
until Python 2 support is dropped
.. note::
In the *very rare* cases where you *need* to differentiate between
- Python 2 and Python 3, use the :data:`odoo.tools.pycompat.PY2` flag.
+ Python 2 and Python 3, use the :data:`flectra.tools.pycompat.PY2` flag.
Semantics changes
=================
@@ -97,7 +97,7 @@ When discovered, this can be fixed by one of:
* using different checking method (e.g. when serialising sets or dictionaries
and checking against the specific serialised value)
* fixing dependencies
-* using a ``collections.OrderedDict`` or ``odoo.tools.misc.OrderedSet`` instead
+* using a ``collections.OrderedDict`` or ``flectra.tools.misc.OrderedSet`` instead
of a regular one, they guarantee order of iteration is order of insertion
* sorting the collection's items before iterating over them (this may require
adding some sort of iteration key to the items)
@@ -117,7 +117,7 @@ library:
* ``urllib``, ``urllib2`` and ``urlparse`` were redistributed across
``urllib.parse`` and ``urllib.request``.
- Since `requests`_ and `werkzeug`_ are already hard dependencies of Odoo,
+ Since `requests`_ and `werkzeug`_ are already hard dependencies of Flectra,
replace ``urllib[2].urlopen``/``urllib2.Request`` uses by `requests`_, and
``urlparse`` and a few utilty functions (``urllib.quote``,
``urllib.urlencode``) are available through ``werkzeug.urls``, a backport
@@ -125,8 +125,8 @@ library:
.. warning:: `requests`_ does not raise by default on non-200 responses
-* ``cgi.escape`` (HTML escaping) is deprecated in Python 3, prefer Odoo's own
- :func:`odoo.tools.misc.html_encode`.
+* ``cgi.escape`` (HTML escaping) is deprecated in Python 3, prefer Flectra's own
+ :func:`flectra.tools.misc.html_encode`.
* Most of ``types``'s content has been stripped out in Python 3: only
"internal" interpreter types (e.g. CodeType, FrameType, ...) have been left
in, other types can be obtained directly from the corresponding builtin or
@@ -149,7 +149,7 @@ PYTHONPATH.
Furthermore if a sibling file is named the same as top-level package, the
library becomes inaccessible to both the file itself ans siblings, this has
-actually happened in Odoo with :mod:`odoo.tools.mimetypes`.
+actually happened in Flectra with :mod:`flectra.tools.mimetypes`.
Additionally, relative imports allow navigating "up" the tree by using
multiple leading ``.``.
@@ -300,7 +300,7 @@ under the single ``int`` type.
* the ``L`` suffix for integer literals must be removed
* calls to ``long`` must be replaced by calls to ``int``
* ``(int, long)`` for type-checking purposes must be replaced by
- :py:data:`odoo.tools.pycompat.integer_types`
+ :py:data:`flectra.tools.pycompat.integer_types`
* the ``L`` suffix on numbers is unsupported in Python 3, and unnecessary in
@@ -311,8 +311,8 @@ under the single ``int`` type.
subtype of ``int`` (nor the reverse), and ``isinstance(value, (int, long))``
is thus generally necessary to catch all integrals.
- For that case, Odoo 11 now provides a compatibility module with an
- :py:data:`~odoo.tools.pycompat.integer_types` definition which can be used
+ For that case, Flectra 11 now provides a compatibility module with an
+ :py:data:`~flectra.tools.pycompat.integer_types` definition which can be used
for type-testing.
It is a tuple of types so when used with ``isinstance`` it can be provided
@@ -411,13 +411,13 @@ Both versions have the following prefixes for string literals:
For best cross-version compatibility you should avoid unprefixed string
literals unless you *specifically* need a "native string" [#native-string]_.
-For easier type-testing, :mod:`odoo.tools.pycompat` provides the following
+For easier type-testing, :mod:`flectra.tools.pycompat` provides the following
constants:
-* :data:`~odoo.tools.pycompat.string_types` is an alias/type tuple for testing
+* :data:`~flectra.tools.pycompat.string_types` is an alias/type tuple for testing
string types, essentially a replacement of testing for ``basestring`` or
``(str, unicode)``.
-* :data:`~odoo.tools.pycompat.text_type` is the proper *text* type for the
+* :data:`~flectra.tools.pycompat.text_type` is the proper *text* type for the
current version, it should mostly be used for converting non-bytes objects
to text.
* ``bytes`` should be avoided for type conversions, though it can be used to
@@ -466,12 +466,12 @@ significant ways:
* Python 3's CSV only works on *text streams* and extract text values
* And ``io`` doesn't provide "native string" streaming facilities.
-However with respect to Odoo it turns out most or all uses of ``csv`` fit
+However with respect to Flectra it turns out most or all uses of ``csv`` fit
inside a model of *byte stream to and from text values*.
The latter is thus a model implemented by cross-version wrappers
-:func:`odoo.tools.pycompat.csv_reader` and
-:func:`odoo.tools.pycompat.csv_writer`: they take a *UTF-8 byte stream* and
+:func:`flectra.tools.pycompat.csv_reader` and
+:func:`flectra.tools.pycompat.csv_writer`: they take a *UTF-8 byte stream* and
read or write *text* values.
.. _hash randomisation: http://bugs.python.org/issue13703
diff --git a/doc/reference/actions.rst b/doc/reference/actions.rst
index 904cb89d..1d34ebe1 100644
--- a/doc/reference/actions.rst
+++ b/doc/reference/actions.rst
@@ -52,7 +52,7 @@ Its fields are:
an optional database id (or ``False``). If no id is provided, the client
should fetch the default view of the specified type for the requested
model (this is automatically done by
- :meth:`~odoo.models.Model.fields_view_get`). The first type of the
+ :meth:`~flectra.models.Model.fields_view_get`). The first type of the
list is the default view type and will be open by default when the action
is executed. Each view type should be present at most once in the list
``res_id`` (optional)
@@ -147,7 +147,7 @@ The server-side composition of the ``views`` sequence is the following:
URL Actions (``ir.actions.act_url``)
====================================
-Allow opening a URL (website/web page) via an Odoo action. Can be customized
+Allow opening a URL (website/web page) via an Flectra action. Can be customized
via two fields:
``url``
@@ -160,11 +160,11 @@ via two fields:
{
"type": "ir.actions.act_url",
- "url": "http://odoo.com",
+ "url": "http://flectra.com",
"target": "self",
}
-will replace the current content section by the Odoo home page.
+will replace the current content section by the Flectra home page.
.. _reference/actions/server:
@@ -184,7 +184,7 @@ specific or generic actions based on their ``state``. Some fields (and
corresponding behaviors) are shared between states:
``model_id``
- Odoo model linked to the action, made available in
+ Flectra model linked to the action, made available in
:ref:`evaluation contexts `
``condition`` (optional)
evaluated as Python code using the server action's
@@ -248,8 +248,8 @@ from the UI, but not from :ref:`data files `.
``object_create``
-----------------
-Creates a new record, from scratch (via :meth:`~odoo.models.Model.create`)
-or by copying an existing record (via :meth:`~odoo.models.Model.copy`)
+Creates a new record, from scratch (via :meth:`~flectra.models.Model.create`)
+or by copying an existing record (via :meth:`~flectra.models.Model.copy`)
``use_create``
the creation policy, one of:
@@ -264,7 +264,7 @@ or by copying an existing record (via :meth:`~odoo.models.Model.copy`)
copies an other record, obtained via ``ref_object``
``fields_lines``
fields to override when creating or copying the record.
- :class:`~odoo.fields.One2many` with the fields:
+ :class:`~flectra.fields.One2many` with the fields:
``col1``
``ir.model.fields`` to set in the model implied by ``use_create``
@@ -278,7 +278,7 @@ or by copying an existing record (via :meth:`~odoo.models.Model.copy`)
model in which to create a new record, if ``use_create`` is set to
``new_other``
``ref_object``
- :class:`~odoo.fields.Reference` to an arbitrary record to copy, used if
+ :class:`~flectra.fields.Reference` to an arbitrary record to copy, used if
``use_create`` is set to ``copy_other``
``link_new_record``
boolean flag linking the newly created record to the current one via a
@@ -373,10 +373,10 @@ Triggers the printing of a report
``report_name``
the name of your report (which will be the name of the PDF output)
``groups_id``
- :class:`~odoo.fields.Many2many` field to the groups allowed to view/use
+ :class:`~flectra.fields.Many2many` field to the groups allowed to view/use
the current report
``paperformat_id``
- :class:`~odoo.fields.Many2one` field to the paper format you wish to
+ :class:`~flectra.fields.Many2one` field to the paper format you wish to
use for this report (if not specified, the company format will be used)
``attachment_use``
if set to ``True``, the report is only generated once the first time it is
diff --git a/doc/reference/cmdline.rst b/doc/reference/cmdline.rst
index 7a2bf086..5d132bd1 100644
--- a/doc/reference/cmdline.rst
+++ b/doc/reference/cmdline.rst
@@ -3,7 +3,7 @@
.. _reference/cmdline:
================================
-Command-line interface: odoo-bin
+Command-line interface: flectra-bin
================================
.. _reference/cmdline/server:
@@ -11,7 +11,7 @@ Command-line interface: odoo-bin
Running the server
==================
-.. program:: odoo-bin
+.. program:: flectra-bin
.. option:: -d , --database
@@ -96,7 +96,7 @@ Running the server
.. option:: -s, --save
saves the server configuration to the current configuration file
- (:file:`{$HOME}/.odoorc` by default, and can be overridden using
+ (:file:`{$HOME}/.flectrarc` by default, and can be overridden using
:option:`-c`)
.. option:: --proxy-mode
@@ -158,12 +158,12 @@ database
- ``%h`` is replaced by the whole hostname the request is made on.
- ``%d`` is replaced by the subdomain the request is made on, with the
- exception of ``www`` (so domain ``odoo.com`` and ``www.odoo.com`` both
- match the database ``odoo``).
+ exception of ``www`` (so domain ``flectra.com`` and ``www.flectra.com`` both
+ match the database ``flectra``).
These operations are case sensitive. Add option ``(?i)`` to match all
- databases (so domain ``odoo.com`` using ``(?i)%d`` matches the database
- ``Odoo``).
+ databases (so domain ``flectra.com`` using ``(?i)%d`` matches the database
+ ``Flectra``).
.. option:: --db-template
@@ -197,12 +197,12 @@ built-in HTTP
.. option:: --longpolling-port
TCP port for long-polling connections in multiprocessing or gevent mode,
- defaults to 7072. Not used in default (threaded) mode.
+ defaults to 8072. Not used in default (threaded) mode.
logging
-------
-By default, Odoo displays all logging of level_ ``info`` except for workflow
+By default, Flectra displays all logging of level_ ``info`` except for workflow
logging (``warning`` only), and log output is sent to ``stdout``. Various
options are available to redirect logging to other destinations and to
customize the amount of logging output
@@ -236,7 +236,7 @@ customize the amount of logging output
.. option:: --log-handler
:samp:`{LOGGER}:{LEVEL}`, enables ``LOGGER`` at the provided ``LEVEL``
- e.g. ``odoo.models:DEBUG`` will enable all logging messages at or above
+ e.g. ``flectra.models:DEBUG`` will enable all logging messages at or above
``DEBUG`` level in the models.
* The colon ``:`` is mandatory
@@ -247,36 +247,36 @@ customize the amount of logging output
.. code-block:: console
- $ odoo-bin --log-handler :DEBUG --log-handler werkzeug:CRITICAL --log-handler odoo.fields:WARNING
+ $ flectra-bin --log-handler :DEBUG --log-handler werkzeug:CRITICAL --log-handler flectra.fields:WARNING
.. option:: --log-request
enable DEBUG logging for RPC requests, equivalent to
- ``--log-handler=odoo.http.rpc.request:DEBUG``
+ ``--log-handler=flectra.http.rpc.request:DEBUG``
.. option:: --log-response
enable DEBUG logging for RPC responses, equivalent to
- ``--log-handler=odoo.http.rpc.response:DEBUG``
+ ``--log-handler=flectra.http.rpc.response:DEBUG``
.. option:: --log-web
enables DEBUG logging of HTTP requests and responses, equivalent to
- ``--log-handler=odoo.http:DEBUG``
+ ``--log-handler=flectra.http:DEBUG``
.. option:: --log-sql
enables DEBUG logging of SQL querying, equivalent to
- ``--log-handler=odoo.sql_db:DEBUG``
+ ``--log-handler=flectra.sql_db:DEBUG``
.. option:: --log-level
Shortcut to more easily set predefined levels on specific loggers. "real"
levels (``critical``, ``error``, ``warn``, ``debug``) are set on the
- ``odoo`` and ``werkzeug`` loggers (except for ``debug`` which is only
- set on ``odoo``).
+ ``flectra`` and ``werkzeug`` loggers (except for ``debug`` which is only
+ set on ``flectra``).
- Odoo also provides debugging pseudo-levels which apply to different sets
+ Flectra also provides debugging pseudo-levels which apply to different sets
of loggers:
``debug_sql``
@@ -284,11 +284,11 @@ customize the amount of logging output
equivalent to ``--log-sql``
``debug_rpc``
- sets the ``odoo`` and HTTP request loggers to ``debug``
+ sets the ``flectra`` and HTTP request loggers to ``debug``
equivalent to ``--log-level debug --log-request``
``debug_rpc_answer``
- sets the ``odoo`` and HTTP request and response loggers to
+ sets the ``flectra`` and HTTP request and response loggers to
``debug``
equivalent to ``--log-level debug --log-request --log-response``
@@ -310,7 +310,7 @@ emails
.. option:: --email-from
- Email address used as when Odoo needs to send mails
+ Email address used as when Flectra needs to send mails
.. option:: --smtp
@@ -320,7 +320,7 @@ emails
.. option:: --smtp-ssl
- If set, odoo should use SSL/STARTSSL SMTP connections
+ If set, flectra should use SSL/STARTSSL SMTP connections
.. option:: --smtp-user
@@ -336,14 +336,14 @@ emails
Scaffolding
===========
-.. program:: odoo-bin scaffold
+.. program:: flectra-bin scaffold
Scaffolding is the automated creation of a skeleton structure to simplify
-bootstrapping (of new modules, in the case of Odoo). While not necessary it
+bootstrapping (of new modules, in the case of Flectra). While not necessary it
avoids the tedium of setting up basic structures and looking up what all
starting requirements are.
-Scaffolding is available via the :command:`odoo-bin scaffold` subcommand.
+Scaffolding is available via the :command:`flectra-bin scaffold` subcommand.
.. option:: -t
@@ -365,7 +365,7 @@ Scaffolding is available via the :command:`odoo-bin scaffold` subcommand.
Configuration file
==================
-.. program:: odoo-bin
+.. program:: flectra-bin
Most of the command-line options can also be specified via a configuration
file. Most of the time, they use similar names with the prefix ``-`` removed
@@ -384,9 +384,9 @@ Some conversions don't match the pattern:
* :option:`--i18n-import` and :option:`--i18n-export` aren't available at all
from configuration files
-The default configuration file is :file:`{$HOME}/.odoorc` which
-can be overridden using :option:`--config `. Specifying
-:option:`--save ` will save the current configuration state back
+The default configuration file is :file:`{$HOME}/.flectrarc` which
+can be overridden using :option:`--config `. Specifying
+:option:`--save ` will save the current configuration state back
to that file.
.. _jinja2: http://jinja.pocoo.org
diff --git a/doc/reference/data.rst b/doc/reference/data.rst
index fd597fcb..55a936cd 100644
--- a/doc/reference/data.rst
+++ b/doc/reference/data.rst
@@ -6,7 +6,7 @@
Data Files
==========
-Odoo is greatly data-driven, and a big part of modules definition is thus
+Flectra is greatly data-driven, and a big part of modules definition is thus
the definition of the various records it manages: UI (menus and views),
security (access rights and access rules), reports and plain data are all
defined via records.
@@ -14,18 +14,18 @@ defined via records.
Structure
=========
-The main way to define data in Odoo is via XML data files: The broad structure
+The main way to define data in Flectra is via XML data files: The broad structure
of an XML data file is the following:
-* Any number of operation elements within the root element ``odoo``
+* Any number of operation elements within the root element ``flectra``
.. code-block:: xml
-
+
...
-
+
Data files are executed sequentially, operations can only refer to the result
of operations defined previously
@@ -77,13 +77,13 @@ Nothing
Will evaluate the domain, search the field's model using it and set the
search's result as the field's value. Will only use the first result if
- the field is a :class:`~odoo.fields.Many2one`
+ the field is a :class:`~flectra.fields.Many2one`
``ref``
if a ``ref`` attribute is provided, its value must be a valid
:term:`external id`, which will be looked up and set as the field's value.
- Mostly for :class:`~odoo.fields.Many2one` and
- :class:`~odoo.fields.Reference` fields
+ Mostly for :class:`~flectra.fields.Many2one` and
+ :class:`~flectra.fields.Reference` fields
``type``
if a ``type`` attribute is provided, it is used to interpret and convert
the field's content. The field's content can be provided through an
@@ -157,7 +157,7 @@ values).
Shortcuts
=========
-Because some important structural models of Odoo are complex and involved,
+Because some important structural models of Flectra are complex and involved,
data files provide shorter alternatives to defining them using
:ref:`record tags `:
@@ -243,14 +243,14 @@ For this case, data files can also use csv_, this is often the case for
Here's the first lines of the data file defining US states
``res.country.state.csv``
-.. literalinclude:: ../../odoo/addons/base/res/res.country.state.csv
+.. literalinclude:: ../../flectra/addons/base/res/res.country.state.csv
:language: text
:lines: 1-15
rendered in a more readable format:
.. csv-table::
- :file: ../../odoo/addons/base/res/res.country.state.csv
+ :file: ../../flectra/addons/base/res/res.country.state.csv
:header-rows: 1
:class: table-striped table-hover table-condensed
diff --git a/doc/reference/guidelines.rst b/doc/reference/guidelines.rst
index f04050b0..ff408fc3 100644
--- a/doc/reference/guidelines.rst
+++ b/doc/reference/guidelines.rst
@@ -1,12 +1,12 @@
-:banner: banners/odoo_guideline.jpg
+:banner: banners/flectra_guideline.jpg
.. highlight:: python
===============
-Odoo Guidelines
+Flectra Guidelines
===============
-This page introduces the new Odoo Coding Guidelines. Those aim to improve the quality of the code (e.g. better readability of source) and Odoo Apps. Indeed, proper code eases maintenance, aids debugging, lowers complexity and promotes reliability.
+This page introduces the new Flectra Coding Guidelines. Those aim to improve the quality of the code (e.g. better readability of source) and Flectra Apps. Indeed, proper code eases maintenance, aids debugging, lowers complexity and promotes reliability.
These guidelines should be applied to every new module, and new development.
@@ -16,7 +16,7 @@ These guidelines should be applied to every new module, and new development.
modifying existing files, the original style of the file strictly supersedes
any other style guidelines. In other words, never modify existing files in
order to apply these guidelines, to avoid disrupting the revision history of
- each line. For more details, see our `pull request guide `_.
+ each line. For more details, see our `pull request guide `_.
Module structure
================
@@ -65,7 +65,7 @@ For *controllers*, the only file should be named *main.py*. Otherwise, if you ne
For *static files*, since the resources can be used in different contexts (frontend, backend, both), they will be included in only one bundle. So, CSS/Less, JavaScript and XML files should be suffixed with the name of the bundle type. i.e.: *im_chat_common.css*, *im_chat_common.js* for 'assets_common' bundle, and *im_chat_backend.css*, *im_chat_backend.js* for 'assets_backend' bundle.
If the module owns only one file, the convention will be *.ext* (i.e.: *project.js*).
-Don't link data (image, libraries) outside Odoo: do not use an
+Don't link data (image, libraries) outside Flectra: do not use an
URL to an image but copy it in our codebase instead.
Regarding *data*, split them by purpose: data or demo. The filename will be
@@ -165,7 +165,7 @@ To declare a record in XML, the **record** notation (using **) is recomm
- Use naming convention defined at the next point
- The tag ** is only used to set not-updatable data with ``noupdate=1``.
If there is only not-updatable data in the file, the ``noupdate=1`` can be
- set on the ```` tag and do not set a ```` tag.
+ set on the ```` tag and do not set a ```` tag.
.. code-block:: xml
@@ -181,7 +181,7 @@ To declare a record in XML, the **record** notation (using **) is recomm
-Odoo supports custom tags acting as syntactic sugar:
+Flectra supports custom tags acting as syntactic sugar:
- menuitem: use it as a shortcut to declare a ``ir.ui.menu``
- template: use it to declare a QWeb View requiring only the ``arch`` section of the view.
@@ -291,7 +291,7 @@ Python
PEP8 options
------------
-Using a linter can help show syntax and semantic warnings or errors. Odoo
+Using a linter can help show syntax and semantic warnings or errors. Flectra
source code tries to respect Python standard, but some of them can be ignored.
- E501: line too long
@@ -308,8 +308,8 @@ Imports
The imports are ordered as
#. External libraries (one per line sorted and split in python stdlib)
-#. Imports of ``odoo``
-#. Imports from Odoo modules (rarely, and only if necessary)
+#. Imports of ``flectra``
+#. Imports from Flectra modules (rarely, and only if necessary)
Inside these 3 groups, the imported lines are alphabetically sorted.
@@ -320,14 +320,14 @@ Inside these 3 groups, the imported lines are alphabetically sorted.
import re
import time
from datetime import datetime
- # 2 : imports of odoo
- import odoo
- from odoo import api, fields, models # alphabetically ordered
- from odoo.tools.safe_eval import safe_eval as eval
- from odoo.tools.translate import _
- # 3 : imports from odoo modules
- from odoo.addons.website.models.website import slug
- from odoo.addons.web.controllers.main import login_redirect
+ # 2 : imports of flectra
+ import flectra
+ from flectra import api, fields, models # alphabetically ordered
+ from flectra.tools.safe_eval import safe_eval as eval
+ from flectra.tools.translate import _
+ # 3 : imports from flectra modules
+ from flectra.addons.website.models.website import slug
+ from flectra.addons.web.controllers.main import login_redirect
Idiomatics Python Programming
@@ -478,11 +478,11 @@ So, you can write ``if some_collection:`` instead of ``if len(some_collection):`
interesting: http://python.net/~goodger/projects/pycon/2007/idiomatic/handout.html
(a little bit outdated, but quite relevant)
-Programming in Odoo
+Programming in Flectra
-------------------
- Avoid to create generators and decorators: only use the ones provided by
- the Odoo API.
+ the Flectra API.
- As in python, use ``filtered``, ``mapped``, ``sorted``, ... methods to
ease code reading and performance.
@@ -624,7 +624,7 @@ This recommendation is also relevant for classes, files, modules and packages. (
Never commit the transaction
~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-The Odoo framework is in charge of providing the transactional context for
+The Flectra framework is in charge of providing the transactional context for
all RPC calls. The principle is that a new database cursor is opened at the
beginning of each RPC call, and committed when the call has returned, just
before transmitting the answer to the RPC client, approximately like this:
@@ -693,14 +693,14 @@ they can and will be removed !
Use translation method correctly
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-Odoo uses a GetText-like method named "underscore" ``_( )`` to indicate that
+Flectra uses a GetText-like method named "underscore" ``_( )`` to indicate that
a static string used in the code needs to be translated at runtime using the
language of the context. This pseudo-method is accessed within your code by
importing as follows:
.. code-block:: python
- from odoo.tools.translate import _
+ from flectra.tools.translate import _
A few very important rules must be followed when using it, in order for it to
work and to avoid filling the translations with useless junk.
@@ -769,7 +769,7 @@ to be preserved, but it's important to use these in a sensible and obvious manne
error = _("Answer to question %s is not valid.\n" \
"Please enter an integer value.") % question
-In general in Odoo, when manipulating strings, prefer ``%`` over ``.format()``
+In general in Flectra, when manipulating strings, prefer ``%`` over ``.format()``
(when only one variable to replace in a string), and prefer ``%(varname)`` instead
of position (when multiple variables have to be replaced). This makes the
translation easier for the community translators.
@@ -779,16 +779,16 @@ Symbols and Conventions
-----------------------
- Model name (using the dot notation, prefix by the module name) :
- - When defining an Odoo Model : use singular form of the name (*res.partner*
+ - When defining an Flectra Model : use singular form of the name (*res.partner*
and *sale.order* instead of *res.partnerS* and *saleS.orderS*)
- - When defining an Odoo Transient (wizard) : use ``.``
+ - When defining an Flectra Transient (wizard) : use ``.``
where *related_base_model* is the base model (defined in *models/*) related
to the transient, and *action* is the short name of what the transient do.
For instance : ``account.invoice.make``, ``project.task.delegate.batch``, ...
- When defining *report* model (SQL views e.i.) : use
``.report.``, based on the Transient convention.
-- Odoo Python Class : use camelcase for code.
+- Flectra Python Class : use camelcase for code.
.. code-block:: python
@@ -799,7 +799,7 @@ Symbols and Conventions
- Variable name :
- use camelcase for model variable
- use underscore lowercase notation for common variable.
- - Odoo works with a record or a recordset, don't suffix variable names with
+ - Flectra works with a record or a recordset, don't suffix variable names with
*_id* or *_ids* if they don't contain an id or a list of ids.
.. code-block:: python
@@ -894,7 +894,7 @@ Javascript and CSS
.. code-block:: javascript
- odoo.website.if_dom_contains('.jquery_class_selector', function () {
+ flectra.website.if_dom_contains('.jquery_class_selector', function () {
/*your code here*/
});
@@ -927,7 +927,7 @@ Prefix your commit with
Git will loose track, and the history will be lost !), or simply moving code
from a file to another one.
- **[MERGE]** for merge commits (only for forward/back-port)
-- **[CLA]** for signing the Odoo Individual Contributor License
+- **[CLA]** for signing the Flectra Individual Contributor License
Then, in the message itself, specify the part of the code impacted by
your changes (module name, lib, transversal object, ...) and a description
diff --git a/doc/reference/http.rst b/doc/reference/http.rst
index 9dbb61f7..c8f429e3 100644
--- a/doc/reference/http.rst
+++ b/doc/reference/http.rst
@@ -9,28 +9,28 @@ Web Controllers
Routing
=======
-.. autofunction:: odoo.http.route
+.. autofunction:: flectra.http.route
.. _reference/http/request:
Request
=======
-The request object is automatically set on :data:`odoo.http.request` at
+The request object is automatically set on :data:`flectra.http.request` at
the start of the request
-.. autoclass:: odoo.http.WebRequest
+.. autoclass:: flectra.http.WebRequest
:members:
:member-order: bysource
-.. autoclass:: odoo.http.HttpRequest
+.. autoclass:: flectra.http.HttpRequest
:members:
-.. autoclass:: odoo.http.JsonRequest
+.. autoclass:: flectra.http.JsonRequest
:members:
Response
========
-.. autoclass:: odoo.http.Response
+.. autoclass:: flectra.http.Response
:members:
:member-order: bysource
@@ -44,7 +44,7 @@ Controllers
===========
Controllers need to provide extensibility, much like
-:class:`~odoo.models.Model`, but can't use the same mechanism as the
+:class:`~flectra.models.Model`, but can't use the same mechanism as the
pre-requisites (a database with loaded modules) may not be available yet (e.g.
no database created, or no database selected).
@@ -53,11 +53,11 @@ models:
Controllers are created by :ref:`inheriting ` from
-.. autoclass:: odoo.http.Controller
+.. autoclass:: flectra.http.Controller
-and defining methods decorated with :func:`~odoo.http.route`::
+and defining methods decorated with :func:`~flectra.http.route`::
- class MyController(odoo.http.Controller):
+ class MyController(flectra.http.Controller):
@route('/some_url', auth='public')
def handler(self):
return stuff()
@@ -71,7 +71,7 @@ class and override relevant methods, re-exposing them if necessary::
do_before()
return super(Extension, self).handler()
-* decorating with :func:`~odoo.http.route` is necessary to keep the method
+* decorating with :func:`~flectra.http.route` is necessary to keep the method
(and route) visible: if the method is redefined without decorating, it
will be "unpublished"
* the decorators of all methods are combined, if the overriding method's
diff --git a/doc/reference/javascript.rst b/doc/reference/javascript.rst
index b2d08bb2..17230610 100644
--- a/doc/reference/javascript.rst
+++ b/doc/reference/javascript.rst
@@ -375,10 +375,10 @@ Development Guidelines
name of the component they belong to (creating "informal" namespaces, much
as in C or Objective-C).
* Global selectors should be avoided. Because a component may be used several
- times in a single page (an example in Odoo is dashboards), queries should be
+ times in a single page (an example in Flectra is dashboards), queries should be
restricted to a given component's scope. Unfiltered selections such as
``$(selector)`` or ``document.querySelectorAll(selector)`` will generally
- lead to unintended or incorrect behavior. Odoo Web's
+ lead to unintended or incorrect behavior. Flectra Web's
:class:`~Widget` has an attribute providing its DOM root
(:attr:`~Widget.$el`), and a shortcut to select nodes directly
(:func:`~Widget.$`).
@@ -415,29 +415,29 @@ Development Guidelines
RPC
===
-To display and interact with data, calls to the Odoo server are necessary.
+To display and interact with data, calls to the Flectra server are necessary.
This is performed using :abbr:`RPC `.
-Odoo Web provides two primary APIs to handle this: a low-level
-JSON-RPC based API communicating with the Python section of Odoo
+Flectra Web provides two primary APIs to handle this: a low-level
+JSON-RPC based API communicating with the Python section of Flectra
Web (and of your module, if you have a Python part) and a high-level
-API above that allowing your code to talk directly to high-level Odoo models.
+API above that allowing your code to talk directly to high-level Flectra models.
All networking APIs are :ref:`asynchronous `. As a result,
all of them will return Deferred_ objects (whether they resolve those with
values or not). Understanding how those work before before moving on is
probably necessary.
-High-level API: calling into Odoo models
+High-level API: calling into Flectra models
-------------------------------------------
-Access to Odoo object methods (made available through XML-RPC from the server)
-is done via :class:`Model`. It maps onto the Odoo server objects via two primary
+Access to Flectra object methods (made available through XML-RPC from the server)
+is done via :class:`Model`. It maps onto the Flectra server objects via two primary
methods, :func:`~Model.call` (exported in ``web.Model``) and :func:`~Model.query`
(exported in ``web.DataModel``, only available in the backend client).
:func:`~Model.call` is a direct mapping to the corresponding method of
-the Odoo server object. Its usage is similar to that of the Odoo Model API,
+the Flectra server object. Its usage is similar to that of the Flectra Model API,
with three differences:
* The interface is :ref:`asynchronous `, so instead of
@@ -460,9 +460,9 @@ with three differences:
});
:func:`~Model.query` is a shortcut for a builder-style
-interface to searches (``search`` + ``read`` in Odoo RPC terms). It
-returns a :class:`~odoo.web.Query` object which is immutable but
-allows building new :class:`~odoo.web.Query` instances from the
+interface to searches (``search`` + ``read`` in Flectra RPC terms). It
+returns a :class:`~flectra.web.Query` object which is immutable but
+allows building new :class:`~flectra.web.Query` instances from the
first one, adding new properties or modifiying the parent object's::
Users.query(['name', 'login', 'user_email', 'signature'])
@@ -473,8 +473,8 @@ first one, adding new properties or modifiying the parent object's::
});
The query is only actually performed when calling one of the query
-serialization methods, :func:`~odoo.web.Query.all` and
-:func:`~odoo.web.Query.first`. These methods will perform a new
+serialization methods, :func:`~flectra.web.Query.all` and
+:func:`~flectra.web.Query.first`. These methods will perform a new
RPC call every time they are called.
For that reason, it's actually possible to keep "intermediate" queries
@@ -503,38 +503,38 @@ around and use them differently/add new specifications on them.
:param Array fields: list of fields to fetch during
the search
- :returns: a :class:`~odoo.web.Query` object
+ :returns: a :class:`~flectra.web.Query` object
representing the search to perform
-.. class:: odoo.web.Query(fields)
+.. class:: flectra.web.Query(fields)
The first set of methods is the "fetching" methods. They perform
RPC queries using the internal data of the object they're called
on.
- .. function:: odoo.web.Query.all()
+ .. function:: flectra.web.Query.all()
- Fetches the result of the current :class:`~odoo.web.Query` object's
+ Fetches the result of the current :class:`~flectra.web.Query` object's
search.
:rtype: Deferred>
- .. function:: odoo.web.Query.first()
+ .. function:: flectra.web.Query.first()
Fetches the **first** result of the current
- :class:`~odoo.web.Query`, or ``null`` if the current
- :class:`~odoo.web.Query` does have any result.
+ :class:`~flectra.web.Query`, or ``null`` if the current
+ :class:`~flectra.web.Query` does have any result.
:rtype: Deferred
For example, let's come back to the Belgium PCMN. This chart of accounts is override in this way to add some properties.
@@ -360,7 +361,7 @@ How to create a new bank operation model?
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
.. note::
- How a bank operation model works exactly in Odoo? See `Configure model of entries `_.
+ How a bank operation model works exactly in Flectra? See `Configure model of entries `_.
Since ``V10``, a new feature is available in the bank statement reconciliation widget: the bank operation model.
This allows the user to pre-fill some accounting entries with a single click.
@@ -418,4 +419,4 @@ one to bring all the stuff for your localization module and one more, ``account_
'depends': ['l10n_xx', 'account_reports'],
-Once it's done, you can start the creation of your report statements. The documentation is available in the following `slides `_.
+Once it's done, you can start the creation of your report statements. The documentation is available in the following `slides `_.
diff --git a/doc/webservices/upgrade.rst b/doc/webservices/upgrade.rst
index fa168935..4e3a3d92 100644
--- a/doc/webservices/upgrade.rst
+++ b/doc/webservices/upgrade.rst
@@ -13,11 +13,11 @@ Database Upgrade
Introduction
~~~~~~~~~~~~
-This document describes the API used to upgrade an Odoo database to a
+This document describes the API used to upgrade an Flectra database to a
higher version.
It allows a database to be upgraded without ressorting to the html form at
-https://upgrade.odoo.com
+https://upgrade.flectra.com
Although the database will follow the same process described on that form.
@@ -41,24 +41,24 @@ This action creates a database request with the following information:
* your contract reference
* your email address
-* the target version (the Odoo version you want to upgrade to)
+* the target version (the Flectra version you want to upgrade to)
* the purpose of your request (test or production)
* the database dump name (required but purely informative)
-* optionally the server timezone (for Odoo source version < 6.1)
+* optionally the server timezone (for Flectra source version < 6.1)
The ``create`` method
---------------------
-.. py:function:: https://upgrade.odoo.com/database/v1/create
+.. py:function:: https://upgrade.flectra.com/database/v1/create
Creates a database upgrade request
:param str contract: (required) your enterprise contract reference
:param str email: (required) your email address
- :param str target: (required) the Odoo version you want to upgrade to. Valid choices: 6.0, 6.1, 7.0, 8.0
+ :param str target: (required) the Flectra version you want to upgrade to. Valid choices: 6.0, 6.1, 7.0, 8.0
:param str aim: (required) the purpose of your upgrade database request. Valid choices: test, production.
:param str filename: (required) a purely informative name for you database dump file
- :param str timezone: (optional) the timezone used by your server. Only for Odoo source version < 6.1
+ :param str timezone: (optional) the timezone used by your server. Only for Flectra source version < 6.1
:return: request result
:rtype: JSON dictionary
@@ -150,7 +150,7 @@ Here are 2 examples of database upgrade request creation using:
import pycurl
import json
- CREATE_URL = "https://upgrade.odoo.com/database/v1/create"
+ CREATE_URL = "https://upgrade.flectra.com/database/v1/create"
CONTRACT = "M123456-abcdef"
AIM = "test"
TARGET = "8.0"
@@ -187,7 +187,7 @@ Here are 2 examples of database upgrade request creation using:
TARGET=8.0
EMAIL=john.doe@example.com
FILENAME=db_name.dump
- CREATE_URL="https://upgrade.odoo.com/database/v1/create"
+ CREATE_URL="https://upgrade.flectra.com/database/v1/create"
URL_PARAMS="contract=${CONTRACT}&aim=${AIM}&target=${TARGET}&email=${EMAIL}&filename=${FILENAME}"
curl -sS "${CREATE_URL}?${URL_PARAMS}" > create_result.json
@@ -214,7 +214,7 @@ The ``upload`` method
It's the most simple and most straightforward way of uploading your database dump.
It uses the HTTPS protocol.
-.. py:function:: https://upgrade.odoo.com/database/v1/upload
+.. py:function:: https://upgrade.flectra.com/database/v1/upload
Uploads a database dump
@@ -239,7 +239,7 @@ should be empty if everything went fine.
import pycurl
from urllib import urlencode
- UPLOAD_URL = "https://upgrade.odoo.com/database/v1/upload"
+ UPLOAD_URL = "https://upgrade.flectra.com/database/v1/upload"
DUMPFILE = "openchs.70.cdump"
fields = dict([
@@ -265,7 +265,7 @@ should be empty if everything went fine.
.. code-block:: bash
- UPLOAD_URL="https://upgrade.odoo.com/database/v1/upload"
+ UPLOAD_URL="https://upgrade.flectra.com/database/v1/upload"
DUMPFILE="openchs.70.cdump"
KEY="Aw7pItGVKFuZ_FOR3U8VFQ=="
REQUEST_ID="10534"
@@ -284,7 +284,7 @@ It uses the SFTP protocol and supports resuming.
It will create a temporary SFTP server where you can connect to and allow you
to upload your database dump using an SFTP client.
-.. py:function:: https://upgrade.odoo.com/database/v1/request_sftp_access
+.. py:function:: https://upgrade.flectra.com/database/v1/request_sftp_access
Creates an SFTP server
@@ -315,7 +315,7 @@ The ``request_sftp_access`` method returns a JSON dictionary containing the foll
import pycurl
from urllib import urlencode
- UPLOAD_URL = "https://upgrade.odoo.com/database/v1/request_sftp_access"
+ UPLOAD_URL = "https://upgrade.flectra.com/database/v1/request_sftp_access"
SSH_KEYS="/path/to/your/authorized_keys"
fields = dict([
@@ -337,7 +337,7 @@ The ``request_sftp_access`` method returns a JSON dictionary containing the foll
.. code-block:: bash
- REQUEST_SFTP_ACCESS_URL="https://upgrade.odoo.com/database/v1/request_sftp_access"
+ REQUEST_SFTP_ACCESS_URL="https://upgrade.flectra.com/database/v1/request_sftp_access"
SSH_KEYS=/path/to/your/authorized_keys
KEY="Aw7pItGVKFuZ_FOR3U8VFQ=="
REQUEST_ID="10534"
@@ -386,8 +386,8 @@ your database dump. Here is a sample session using the 'sftp' client:
::
- $ sftp -P 2200 user_10534@upgrade.odoo.com
- Connected to upgrade.odoo.com.
+ $ sftp -P 2200 user_10534@upgrade.flectra.com
+ Connected to upgrade.flectra.com.
sftp> put /path/to/openchs.70.cdump openchs.70.cdump
Uploading /path/to/openchs.70.cdump to /openchs.70.cdump
sftp> ls -l openchs.70.cdump
@@ -406,7 +406,7 @@ database upgrade using a script, you can use a batch file or pipe your commands
::
- echo "put /path/to/openchs.70.cdump openchs.70.cdump" | sftp -b - -P 2200 user_10534@upgrade.odoo.com
+ echo "put /path/to/openchs.70.cdump openchs.70.cdump" | sftp -b - -P 2200 user_10534@upgrade.flectra.com
The ``-b`` parameter takes a filename. If the filename is ``-``, it reads the commands from standard input.
@@ -421,7 +421,7 @@ This action ask the Upgrade Platform to process your database dump.
The ``process`` method
----------------------
-.. py:function:: https://upgrade.odoo.com/database/v1/process
+.. py:function:: https://upgrade.flectra.com/database/v1/process
Process a database dump
@@ -447,7 +447,7 @@ should be empty if everything went fine.
import pycurl
import json
- PROCESS_URL = "https://upgrade.odoo.com/database/v1/process"
+ PROCESS_URL = "https://upgrade.flectra.com/database/v1/process"
fields = dict([
('request', '10534'),
@@ -471,7 +471,7 @@ should be empty if everything went fine.
.. code-block:: bash
- PROCESS_URL="https://upgrade.odoo.com/database/v1/process"
+ PROCESS_URL="https://upgrade.flectra.com/database/v1/process"
KEY="Aw7pItGVKFuZ_FOR3U8VFQ=="
REQUEST_ID="10534"
URL_PARAMS="key=${KEY}&request=${REQUEST_ID}"
@@ -487,7 +487,7 @@ This action ask the status of your database upgrade request.
The ``status`` method
---------------------
-.. py:function:: https://upgrade.odoo.com/database/v1/status
+.. py:function:: https://upgrade.flectra.com/database/v1/status
Ask the status of a database upgrade request
@@ -513,7 +513,7 @@ database upgrade request.
import pycurl
import json
- STATUS_URL = "https://upgrade.odoo.com/database/v1/status"
+ STATUS_URL = "https://upgrade.flectra.com/database/v1/status"
fields = dict([
('request', '10534'),
@@ -535,7 +535,7 @@ database upgrade request.
.. code-block:: bash
- STATUS_URL="https://upgrade.odoo.com/database/v1/status"
+ STATUS_URL="https://upgrade.flectra.com/database/v1/status"
KEY="Aw7pItGVKFuZ_FOR3U8VFQ=="
REQUEST_ID="10534"
URL_PARAMS="key=${KEY}&request=${REQUEST_ID}"
@@ -553,7 +553,7 @@ The ``request`` key contains various useful information about your request:
``email``
the email address you supplied when creating the request
``target``
- the target Odoo version you supplied when creating the request
+ the target Flectra version you supplied when creating the request
``aim``
the purpose (test, production) of your database upgrade request you supplied when creating the request
``filename``
@@ -563,9 +563,9 @@ The ``request`` key contains various useful information about your request:
``state``
the state of your request
``issue_stage``
- the stage of the issue we have create on Odoo main server
+ the stage of the issue we have create on Flectra main server
``issue``
- the id of the issue we have create on Odoo main server
+ the id of the issue we have create on Flectra main server
``status_url``
the URL to access your database upgrade request html page
``notes_url``
@@ -597,7 +597,7 @@ The ``request`` key contains various useful information about your request:
``customer_message``
an important message related to your request
``database_version``
- the guessed Odoo version of your uploaded (not upgraded) database
+ the guessed Flectra version of your uploaded (not upgraded) database
``postgresql``
the guessed Postgresql version of your uploaded (not upgraded) database
``compressions``
@@ -622,13 +622,13 @@ The ``request`` key contains various useful information about your request:
"state": "draft",
"issue_stage": "new",
"issue": 648398,
- "status_url": "https://upgrade.odoo.com/database/eu1/10534/Aw7pItGVKFuZ_FOR3U8VFQ==/status",
- "notes_url": "https://upgrade.odoo.com/database/eu1/10534/Aw7pItGVKFuZ_FOR3U8VFQ==/upgraded/notes",
- "original_sql_url": "https://upgrade.odoo.com/database/eu1/10534/Aw7pItGVKFuZ_FOR3U8VFQ==/original/sql",
- "original_dump_url": "https://upgrade.odoo.com/database/eu1/10534/Aw7pItGVKFuZ_FOR3U8VFQ==/original/archive",
- "upgraded_sql_url": "https://upgrade.odoo.com/database/eu1/10534/Aw7pItGVKFuZ_FOR3U8VFQ==/upgraded/sql",
- "upgraded_dump_url": "https://upgrade.odoo.com/database/eu1/10534/Aw7pItGVKFuZ_FOR3U8VFQ==/upgraded/archive",
- "modules_url": "https://upgrade.odoo.com/database/eu1/10534/Aw7pItGVKFuZ_FOR3U8VFQ==/modules/archive",
+ "status_url": "https://upgrade.flectra.com/database/eu1/10534/Aw7pItGVKFuZ_FOR3U8VFQ==/status",
+ "notes_url": "https://upgrade.flectra.com/database/eu1/10534/Aw7pItGVKFuZ_FOR3U8VFQ==/upgraded/notes",
+ "original_sql_url": "https://upgrade.flectra.com/database/eu1/10534/Aw7pItGVKFuZ_FOR3U8VFQ==/original/sql",
+ "original_dump_url": "https://upgrade.flectra.com/database/eu1/10534/Aw7pItGVKFuZ_FOR3U8VFQ==/original/archive",
+ "upgraded_sql_url": "https://upgrade.flectra.com/database/eu1/10534/Aw7pItGVKFuZ_FOR3U8VFQ==/upgraded/sql",
+ "upgraded_dump_url": "https://upgrade.flectra.com/database/eu1/10534/Aw7pItGVKFuZ_FOR3U8VFQ==/upgraded/archive",
+ "modules_url": "https://upgrade.flectra.com/database/eu1/10534/Aw7pItGVKFuZ_FOR3U8VFQ==/modules/archive",
"filesize": "912.99 Kb",
"database_uuid": null,
"created_at": "2015-09-09 07:13:49",
@@ -666,8 +666,8 @@ your database dump. Here is a sample session using the 'sftp' client:
::
- $ sftp -P 2200 user_10534@upgrade.odoo.com
- Connected to upgrade.odoo.com.
+ $ sftp -P 2200 user_10534@upgrade.flectra.com
+ Connected to upgrade.flectra.com.
sftp> get upgraded_openchs.70.cdump /path/to/upgraded_openchs.70.cdump
Downloading /upgraded_openchs.70.cdump to /path/to/upgraded_openchs.70.cdump