odoo-forge-bundle 0.1.0

package/payload/skills/odoo18-docs/references/docs/developer/tutorials/server_framework_101/12_inheritance.md

@@ -0,0 +1,248 @@
+---
+title: "Chapter 12: Inheritance"
+source_url: "https://docs.odoo.sbggai.top/developer/tutorials/server_framework_101/12_inheritance.html"
+---
+
+=======================
+# Chapter 12: Inheritance
+
+A powerful aspect of Odoo is its modularity. A module is dedicated to a business need, but
+modules can also interact with one another. This is useful for extending the functionality of an existing
+module. For example, in our real estate scenario we want to display the list of a salesperson's properties
+directly in the regular user view.
+
+But before going through the specific Odoo module inheritance, let's see how we can alter the
+behavior of the standard CRUD (Create, Retrieve, Update or Delete) methods.
+
+# Python Inheritance
+
+> **note**:
+>     **Goal**: at the end of this section:
+
+    - It should not be possible to delete a property which is not new or cancelled.
+
+    .. image:: 12_inheritance/unlink.gif
+        :align: center
+        :alt: Unlink
+
+    - When an offer is created, the property state should change to 'Offer Received'
+    - It should not be possible to create an offer with a lower price than an existing offer
+
+    .. image:: 12_inheritance/create.gif
+        :align: center
+        :alt: Create
+
+In our real estate module, we never had to develop anything specific to be able to do the
+standard CRUD actions. The Odoo framework provides the necessary
+tools to do them. In fact, such actions are already included in our model thanks to classical
+Python inheritance::
+
+    from odoo import fields, models
+
+    class TestModel(models.Model):
+        _name = "test_model"
+        _description = "Test Model"
+
+        ...
+
+Our `class TestModel` inherits from :class:`~odoo.models.Model` which provides
+:meth:`~odoo.models.Model.create`, :meth:`~odoo.models.Model.read`, :meth:`~odoo.models.Model.write`
+and :meth:`~odoo.models.Model.unlink`.
+
+These methods (and any other method defined on :class:`~odoo.models.Model`) can be extended to add
+specific business logic::
+
+    from odoo import fields, models
+
+    class TestModel(models.Model):
+        _name = "test_model"
+        _description = "Test Model"
+
+        ...
+
+        @api.model
+        def create(self, vals):
+            # Do some business logic, modify vals...
+            ...
+            # Then call super to execute the parent method
+            return super().create(vals)
+
+The decorator :func:`~odoo.api.model` is necessary for the :meth:`~odoo.models.Model.create`
+method because the content of the recordset `self` is not relevant in the context of creation,
+but it is not necessary for the other CRUD methods.
+
+It is also important to note that even though we can directly override the
+:meth:`~odoo.models.Model.unlink` method, you will almost always want to write a new method with
+the decorator :func:`~odoo.api.ondelete` instead. Methods marked with this decorator will be
+called during :meth:`~odoo.models.Model.unlink` and avoids some issues that can occur during
+uninstalling the model's module when :meth:`~odoo.models.Model.unlink` is directly overridden.
+
+In Python 3, `super()` is equivalent to `super(TestModel, self)`. The latter may be necessary
+when you need to call the parent method with a modified recordset.
+
+.. danger::
+
+    - It is very important to **always** call `super()` to avoid breaking the flow. There are
+      only a few very specific cases where you don't want to call it.
+    - Make sure to **always** return data consistent with the parent method. For example, if
+      the parent method returns a `dict()`, your override must also return a `dict()`.
+
+.. exercise:: Add business logic to the CRUD methods.
+
+    - Prevent deletion of a property if its state is not 'New' or 'Cancelled'
+
+    Tip: create a new method with the :func:`~odoo.api.ondelete` decorator and remember that
+    `self` can be a recordset with more than one record.
+
+    - At offer creation, set the property state to 'Offer Received'. Also raise an error if the user
+      tries to create an offer with a lower amount than an existing offer.
+
+    Tip: the `property_id` field is available in the `vals`, but it is an `int`. To
+    instantiate an `estate.property` object, use `self.env[model_name].browse(value)`
+    ([example ](https://github.com/odoo/odoo/blob/136e4f66cd5cafe7df450514937c7218c7216c93/addons/gamification/models/badge.py#L57)_)
+
+# Model Inheritance
+
+**Reference**: the documentation related to this topic can be found in
+:ref:`reference/orm/inheritance`.
+
+In our real estate module, we would like to display the list of properties linked to a salesperson
+directly in the Settings / Users & Companies / Users form view. To do this, we need to add a field to
+the `res.users` model and adapt its view to show it.
+
+Odoo provides two *inheritance* mechanisms to extend an existing model in a modular way.
+
+The first inheritance mechanism allows modules to modify the behavior of a model defined in an
+another module by:
+
+- adding fields to the model,
+- overriding the definition of fields in the model,
+- adding constraints to the model,
+- adding methods to the model,
+- overriding existing methods in the model.
+
+The second inheritance mechanism (delegation) allows every record of a model to be linked
+to a parent model's record and provides transparent access to the
+fields of this parent record.
+
+.. image:: 12_inheritance/inheritance_methods.png
+    :align: center
+    :alt: Inheritance Methods
+
+In Odoo, the first mechanism is by far the most used. In our case, we want to add a field to an
+existing model, which means we will use the first mechanism. For example::
+
+    from odoo import fields, models
+
+    class InheritedModel(models.Model):
+        _inherit = "inherited.model"
+
+        new_field = fields.Char(string="New Field")
+
+A practical example where two fields are added to
+a model can be found
+[here ](https://github.com/odoo/odoo/blob/60e9410e9aa3be4a9db50f6f7534ba31fea3bc29/addons/account_fleet/models/account_move.py#L39-L47)_.
+
+By convention, each inherited model is defined in its own Python file. In our example, it would be
+`models/inherited_model.py`.
+
+.. exercise:: Add a field to Users.
+
+    - Add the following field to `res.users`:
+
+    ===================== ================================================================
+    Field                 Type
+    ===================== ================================================================
+    property_ids          One2many inverse of the field that references the salesperson in
+                          `estate.property`
+    ===================== ================================================================
+
+    - Add a domain to the field so it only lists the available properties.
+
+In the next section let's add the field to the view and check that everything is working well!
+
+# View Inheritance
+
+**Reference**: the documentation related to this topic can be found in
+:ref:`reference/view_records/inheritance`.
+
+> **note**:
+>     **Goal**: at the end of this section, the list of available properties linked
+    to a salesperson should be displayed in their user form view
+
+    .. image:: 12_inheritance/users.png
+        :align: center
+        :alt: Users
+
+Instead of modifying existing views in place (by overwriting them), Odoo
+provides view inheritance where children 'extension' views are applied on top of
+root views. These extension can both add and remove content from their parent view.
+
+An extension view references its parent using the `inherit_id` field.
+Instead of a single view, its `arch` field contains a number of
+`xpath` elements that select and alter the content of their parent view:
+
+```xml
+
+    <record id="inherited_model_view_form" model="ir.ui.view">
+        <field name="name">inherited.model.form.inherit.test</field>
+        <field name="model">inherited.model</field>
+        <field name="inherit_id" ref="inherited.inherited_model_view_form"/>
+        <field name="arch" type="xml">
+            <!-- find field description and add the field
+                 new_field after it -->
+            <xpath expr="//field[@name='description']" position="after">
+              <field name="new_field"/>
+            </xpath>
+        </field>
+    </record>
+
+`expr`
+    An XPath_ expression selecting a single element in the parent view.
+    Raises an error if it matches no element or more than one
+`position`
+    Operation to apply to the matched element:
+
+    `inside`
+        appends `xpath`'s body to the end of the matched element
+    `replace`
+        replaces the matched element with the `xpath`'s body, replacing any `$0` node occurrence
+        in the new body with the original element
+    `before`
+        inserts the `xpath`'s body as a sibling before the matched element
+    `after`
+        inserts the `xpaths`'s body as a sibling after the matched element
+    `attributes`
+        alters the attributes of the matched element using the special
+        `attribute` elements in the `xpath`'s body
+
+When matching a single element, the `position` attribute can be set directly
+on the element to be found. Both inheritances below have the same result.
+
+```xml
+
+    <xpath expr="//field[@name='description']" position="after">
+        <field name="idea_ids" />
+    </xpath>
+
+    <field name="description" position="after">
+        <field name="idea_ids" />
+    </field>
+
+An example of a view inheritance extension can be found
+[here ](https://github.com/odoo/odoo/blob/691d1f087040f1ec7066e485d19ce3662dfc6501/addons/account_fleet/views/account_move_views.xml#L3-L17)_.
+
+.. exercise:: Add fields to the Users view.
+
+    Add the `property_ids` field to the `base.view_users_form` in a new notebook page.
+
+    Tip: an example an inheritance of the users' view can be found
+    [here ](https://github.com/odoo/odoo/blob/691d1f087040f1ec7066e485d19ce3662dfc6501/addons/gamification/views/res_users_views.xml#L5-L14)_.
+
+Inheritance is extensively used in Odoo due to its modular concept. Do not hesitate to read
+the corresponding documentation for more info!
+
+In the :doc:`next chapter <13_other_module>`, we will learn how to
+interact with other modules.
+
+.. _XPath: https://w3.org/TR/xpath

package/payload/skills/odoo18-docs/references/docs/developer/tutorials/server_framework_101/13_other_module.md

@@ -0,0 +1,170 @@
+---
+title: "Chapter 13: Interact With Other Modules"
+source_url: "https://docs.odoo.sbggai.top/developer/tutorials/server_framework_101/13_other_module.html"
+---
+
+=======================================
+# Chapter 13: Interact With Other Modules
+
+In the :doc:`previous chapter <12_inheritance>`, we used inheritance to
+modify the behavior of a module. In our real estate scenario, we would like to go a step further
+and be able to generate invoices for our customers. Odoo provides an Invoicing module, so it
+would be neat to create an invoice directly from our real estate module, i.e. once a property
+is set to 'Sold', an invoice is created in the Invoicing application.
+
+# Concrete Example: Account Move
+
+> **note**:
+>     **Goal**: at the end of this section:
+
+    - A new module `estate_account` should be created
+    - When a property is sold, an invoice should be issued for the buyer
+
+    .. image:: 13_other_module/create_inv.gif
+        :align: center
+        :alt: Invoice creation
+
+Any time we interact with another module, we need to keep in mind the modularity. If we intend
+to sell our application to real estate agencies, some may want the invoicing feature but
+others may not want it.
+
+## Link Module
+
+The common approach for such use cases is to create a 'link' module. In our case, the module
+would depend on `estate` and `account` and would include the invoice creation logic
+of the estate property. This way the real estate and the accounting modules can be installed
+independently. When both are installed, the link module provides the new feature.
+
+.. exercise:: Create a link module.
+
+    Create the `estate_account` module, which depends on the `estate` and `account` modules.
+    For now, it will be an empty shell.
+
+    Tip: you already did this at the
+    :doc:`beginning of the tutorial <02_newapp>`. The process is very
+    similar.
+
+When the `estate_account` module appears in the list, go ahead and install it! You'll notice that
+the Invoicing application is installed as well. This is expected since your module depends on it.
+If you uninstall the Invoicing application, your module will be uninstalled as well.
+
+.. _tutorials/server_framework_101/13_other_module/create:
+
+## Invoice Creation
+
+It's now time to generate the invoice. We want to add functionality to the
+`estate.property` model, i.e. we want to add some extra logic for when a property is sold.
+Does that sound familiar? If not, it's a good idea to go back to the
+:doc:`previous chapter <12_inheritance>` since you might have missed
+something ;-)
+
+As a first step, we need to extend the action called when pressing the
+:doc:`'Sold' button <09_actions>` on a property. To do so, we need to
+create a :doc:`model inheritance <12_inheritance>` in the `estate_account`
+module for the `estate.property` model. For now, the overridden action will simply return the
+`super` call. Maybe an example will make things clearer::
+
+    from odoo import models
+
+    class InheritedModel(models.Model):
+        _inherit = "inherited.model"
+
+        def inherited_action(self):
+            return super().inherited_action()
+
+A practical example can be found
+[here ](https://github.com/odoo/odoo/blob/f1f48cdaab3dd7847e8546ad9887f24a9e2ed4c1/addons/event_sale/models/account_move.py#L7-L16)_.
+
+.. exercise:: Add the first step of invoice creation.
+
+    - Create a `estate_property.py` file in the correct folder of the `estate_account` module.
+    - `_inherit` the `estate.property` model.
+    - Override the `action_sold` method (you might have named it differently) to return the `super`
+      call.
+
+    Tip: to make sure it works, add a `print` or a debugger breakpoint in the overridden method.
+
+Is it working? If not, maybe check that all Python files are correctly imported.
+
+If the override is working, we can move forward and create the invoice. Unfortunately, there
+is no easy way to know how to create any given object in Odoo. Most of the time, it is necessary
+to have a look at its model to find the required fields and provide appropriate values.
+
+A good way to learn is to look at how other modules already do what you want to do. For example, one of
+the basic flows of Sales is the creation of an invoice from a sales order. This looks like a good
+starting point since it does exactly what we want to do. Take some time to read and understand the
+[_create_invoices ](https://github.com/odoo/odoo/blob/f1f48cdaab3dd7847e8546ad9887f24a9e2ed4c1/addons/sale/models/sale.py#L610-L717)_
+method. When you are done crying because this simple task looks awfully complex, we can move
+forward in the tutorial.
+
+To create an invoice, we need the following information:
+
+- a `partner_id`: the customer
+- a `move_type`: it has several [possible values ](https://github.com/odoo/odoo/blob/f1f48cdaab3dd7847e8546ad9887f24a9e2ed4c1/addons/account/models/account_move.py#L138-L147)_
+- a `journal_id`: the accounting journal
+
+This is enough to create an empty invoice.
+
+.. exercise:: Add the second step of invoice creation.
+
+    Create an empty `account.move` in the override of the `action_sold` method:
+
+    - the `partner_id` is taken from the current `estate.property`
+    - the `move_type` should correspond to a 'Customer Invoice'
+
+    Tips:
+
+    - to create an object, use `self.env[model_name].create(values)`, where `values`
+      is a `dict`.
+    - the `create` method doesn't accept recordsets as field values.
+
+When a property is set to 'Sold', you should now have a new customer invoice created in
+Invoicing / Customers / Invoices.
+
+Obviously we don't have any invoice lines so far. To create an invoice line, we need the following
+information:
+
+- `name`: a description of the line
+- `quantity`
+- `price_unit`
+
+Moreover, an invoice line needs to be linked to an invoice. The easiest and most efficient way
+to link a line to an invoice is to include all lines at invoice creation. To do this, the
+`invoice_line_ids` field is included in the `account.move` creation, which is a
+:class:`~odoo.fields.One2many`. One2many and Many2many use special 'commands' which have been
+made human readable with the :class:`~odoo.fields.Command` namespace. This namespace represents
+a triplet command to execute on a set of records. The triplet was originally the only option to
+do these commands, but it is now standard to use the namespace instead. The format is to place
+them in a list which is executed sequentially. Here is a simple example to include a One2many
+field `line_ids` at creation of a `test_model`::
+
+    from odoo import Command
+
+    def inherited_action(self):
+        self.env["test_model"].create(
+            {
+                "name": "Test",
+                "line_ids": [
+                    Command.create({
+                        "field_1": "value_1",
+                        "field_2": "value_2",
+                    })
+                ],
+            }
+        )
+        return super().inherited_action()
+
+.. exercise:: Add the third step of invoice creation.
+
+    Add two invoice lines during the creation of the `account.move`. Each property sold will
+    be invoiced following these conditions:
+
+    - 6% of the selling price
+    - an additional 100.00 from administrative fees
+
+    Tip: Add the `invoice_line_ids` at creation following the example above.
+    For each line, we need a `name`, `quantity` and `price_unit`.
+
+This chapter might be one of the most difficult that has been covered so far, but it is the closest
+to what Odoo development will be in practice. In the :doc:`next chapter
+<14_qwebintro>`, we will introduce the templating mechanism used in Odoo.

package/payload/skills/odoo18-docs/references/docs/developer/tutorials/server_framework_101/14_qwebintro.md

@@ -0,0 +1,129 @@
+---
+title: "Chapter 14: A Brief History Of QWeb"
+source_url: "https://docs.odoo.sbggai.top/developer/tutorials/server_framework_101/14_qwebintro.html"
+---
+
+===================================
+# Chapter 14: A Brief History Of QWeb
+
+So far the interface design of our real estate module has been rather limited. Building
+a list view is straightforward since only the list of fields is necessary. The same holds true
+for the form view: despite the use of a few tags such as `<group>` or `<page>`, there
+is very little to do in terms of design.
+
+However, if we want to give a unique look to our application, it is necessary to go a step
+further and be able to design new views. Moreover, other features such as PDF reports or
+website pages need another tool to be created with more flexibility: a templating_ engine.
+
+You might already be familiar with existing engines such as Jinja (Python), ERB (Ruby) or
+Twig (PHP). Odoo comes with its own built-in engine: :ref:`reference/qweb`.
+QWeb is the primary templating engine used by Odoo. It is an XML templating engine and used
+mostly to generate HTML fragments and pages.
+
+You probably already have come across the `kanban board`_ in Odoo where the records are
+displayed in a card-like structure. We will build such a view for our real estate module.
+
+# Concrete Example: A Kanban View
+
+**Reference**: the documentation related to this topic can be found in
+:ref:`reference/view_architectures/kanban`.
+
+> **note**:
+>     **Goal**: at the end of this section a Kanban view of the properties should be created:
+
+    .. image:: 14_qwebintro/kanban.png
+        :align: center
+        :alt: Kanban view
+
+In our estate application, we would like to add a Kanban view to display our properties. Kanban
+views are a standard Odoo view (like the form and list views), but their structure is much more
+flexible. In fact, the structure of each card is a mix of form elements (including basic HTML)
+and QWeb. The definition of a Kanban view is similar to the definition of the list and form
+views, except that their root element is `<kanban>`. In its simplest form, a Kanban view
+looks like:
+
+```xml
+
+    <kanban>
+        <templates>
+            <t t-name="kanban-box">
+                <div>
+                    <field name="name"/>
+                </div>
+            </t>
+        </templates>
+    </kanban>
+
+Let's break down this example:
+
+- `<templates>`: defines a list of :ref:`reference/qweb` templates. Kanban views *must* define at
+  least one root template `kanban-box`, which will be rendered once for each record.
+- `<t t-name="kanban-box">`: `<t>` is a placeholder element for QWeb directives. In this case,
+  it is used to set the `name` of the template to `kanban-box`
+- `<field name="name"/>`: this will add the `name` field to the view.
+
+.. exercise:: Make a minimal kanban view.
+
+    Using the simple example provided, create a minimal Kanban view for the properties. The
+    only field to display is the `name`.
+
+    Tip: you must add `kanban` in the `view_mode` of the corresponding
+    `ir.actions.act_window`.
+
+Once the Kanban view is working, we can start improving it. If we want to display an element
+conditionally, we can use the `t-if` directive (see :ref:`reference/qweb/conditionals`).
+
+```xml
+
+    <kanban>
+        <field name="state"/>
+        <templates>
+            <t t-name="kanban-box">
+                <div>
+                    <field name="name"/>
+                    <div t-if="record.state.raw_value == 'new'">
+                        This is new!
+                    </div>
+                </div>
+            </t>
+        </templates>
+    </kanban>
+
+We added a few things:
+
+- `t-if`: the `<div>` element is rendered if the condition is true.
+- `record`: an object with all the requested fields as its attributes. Each field has
+  two attributes `value` and `raw_value`. The former is formatted according to current
+  user parameters and the latter is the direct value from a :meth:`~odoo.models.Model.read`.
+
+In the above example, the field `name` was added in the `<templates>` element, but `state`
+is outside of it. When we need the value of a field but don't want to display it in the view,
+it is possible to add it outside of the `<templates>` element.
+
+.. exercise:: Improve the Kanban view.
+
+    Add the following fields to the Kanban view: expected price, best price, selling price and
+    tags. Pay attention: the best price is only displayed when an offer is received, while the
+    selling price is only displayed when an offer is accepted.
+
+    Refer to the **Goal** of the section for a visual example.
+
+Let's give the final touch to our view: the properties must be grouped by type by default. You
+might want to have a look at the various options described in
+:ref:`reference/view_architectures/kanban`.
+
+.. exercise:: Add default grouping.
+
+    Use the appropriate attribute to group the properties by type by default. You must also prevent
+    drag and drop.
+
+    Refer to the **Goal** of the section for a visual example.
+
+Kanban views are a typical example of how it is always a good idea to start from an existing
+view and fine tune it instead of starting from scratch. There are many options and classes
+available, so... read and learn!
+
+.. _templating:
+    https://en.wikipedia.org/wiki/Template_processor
+.. _kanban board:
+    https://en.wikipedia.org/wiki/Kanban_board

package/payload/skills/odoo18-docs/references/docs/developer/tutorials/server_framework_101/15_final_word.md

@@ -0,0 +1,32 @@
+---
+title: "Chapter 15: The final word"
+source_url: "https://docs.odoo.sbggai.top/developer/tutorials/server_framework_101/15_final_word.html"
+---
+
+==========================
+# Chapter 15: The final word
+
+# Coding guidelines
+
+We will start refactoring the code to match to the Odoo coding guidelines. The guidelines aim
+to improve the quality of the Odoo Apps code.
+
+**Reference**: you will find the Odoo coding guidelines in
+:doc:`/contributing/development/coding_guidelines`.
+
+.. exercise:: Polish your code.
+
+    Refactor your code to respect the coding guidelines. Don't forget to run your linter and
+    respect the module structure, the variable names, the method name convention, the model
+    attribute order and the xml ids.
+
+# Test on the runbot
+
+Odoo has its own :abbr:`CI (Continuous integration)` server named [runbot ](https://runbot.odoo.com/)_. All
+commits, branches and PR will be tested to avoid regressions or breaking of the stable versions.
+All the runs that pass the tests are deployed on their own server with demo data.
+
+.. exercise:: Play with the runbot.
+
+    Feel free to go to the runbot website and open the last stable version of Odoo to check out all the available
+    applications and functionalities.

package/payload/skills/odoo18-docs/references/docs/developer/tutorials/server_framework_101.md

@@ -0,0 +1,47 @@
+---
+title: ""
+source_url: "https://docs.odoo.sbggai.top/developer/tutorials/server_framework_101.html"
+---
+
+:show-content:
+# 
+# Server framework 101
+
+.. toctree::
+    :titlesonly:
+    :glob:
+
+    server_framework_101/*
+
+Welcome to the Server framework 101 tutorial! If you reached this page that means you are
+interested in the development of your own Odoo module. It might also mean that you recently
+joined the Odoo company for a rather technical position. In any case, your journey to the
+technical side of Odoo starts here.
+
+The goal of this tutorial is for you to get an insight of the most important parts of the Odoo
+development framework while developing your own Odoo module to manage real estate assets. The
+chapters should be followed in their given order since they cover the development of a new Odoo
+application from scratch in an incremental way. In other words, each chapter depends on the previous
+one.
+
+> **important**:
+>    Before going further, make sure you have prepared your development environment with the
+   :doc:`setup guide <setup_guide>`.
+
+Ready? Let's get started!
+
+* :doc:`server_framework_101/01_architecture`
+* :doc:`server_framework_101/02_newapp`
+* :doc:`server_framework_101/03_basicmodel`
+* :doc:`server_framework_101/04_securityintro`
+* :doc:`server_framework_101/05_firstui`
+* :doc:`server_framework_101/06_basicviews`
+* :doc:`server_framework_101/07_relations`
+* :doc:`server_framework_101/08_compute_onchange`
+* :doc:`server_framework_101/09_actions`
+* :doc:`server_framework_101/10_constraints`
+* :doc:`server_framework_101/11_sprinkles`
+* :doc:`server_framework_101/12_inheritance`
+* :doc:`server_framework_101/13_other_module`
+* :doc:`server_framework_101/14_qwebintro`
+* :doc:`server_framework_101/15_final_word`