[IMP] developer/{howtos,reference}: update training to match v15 changes

- Reference v15 training solutions
- Refer to Command namespace instead of triplets (e.g.
  Command.create(values) instead of (0, 0, values)
- Add notice about OWL transition
- Add reference to @api.ondelete (instead of override unlink())
- Remove references to SavepointCase (now only TransactionCase) from
  unit test topic

- Also add missing reference documentation for ondelete

closes odoo/documentation#1146

Signed-off-by: Antoine Vandevenne (anv) <anv@odoo.com>

content/developer/howtos/rdtraining/01_architecture.rst

@@ -29,6 +29,12 @@ on your background.
 
 For reference this is the official `Python tutorial`_.
 
+.. note::
+  Since version 15.0, Odoo is actively transitioning to using its own in-house developed `OWL
+  framework <https://odoo.github.io/owl/>`_ as part of its presentation tier. The legacy JavaScript
+  framework is still supported but will be depreciated over time. This will be discussed further in
+  advanced topics.
+
 Odoo modules
 ============
 

content/developer/howtos/rdtraining/13_inheritance.rst

@@ -71,6 +71,12 @@ The decorator :func:`~odoo.api.model` is necessary for the :meth:`~odoo.models.M
 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.
 
@@ -85,8 +91,8 @@ when you need to call the parent method with a modified recordset.
 
     - Prevent deletion of a property if its state is not 'New' or 'Canceled'
 
-    Tip: override :meth:`~odoo.models.Model.unlink` and remember that ``self`` can be a recordset
+    Tip: create a new method with the :func:`~odoo.api.ondelete` decorator and remember that
-    with more than one record.
+    ``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.

content/developer/howtos/rdtraining/14_other_module.rst

@@ -133,24 +133,24 @@ information:
 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' described in
+:class:`~odoo.fields.One2many`. One2many and Many2many use special 'commands' which have been
-:ref:`reference/orm/models/crud`. This format is a list of triplets executed sequentially, where
+made human readable with the :class:`~odoo.fields.Command` namespace. This namespace represents
-each triplet is a command to execute on the set of records. Here is a simple example to include
+a triplet command to execute on a set of records. The triplet was originally the only option to
-a One2many field ``line_ids`` at creation of a ``test.model``:: 
+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({
-                        0,
+                        "field_1": "value_1",
-                        0,
+                        "field_2": "value_2",
-                        {
+                    })
-                            "field_1": "value_1",
-                            "field_2": "value_2",
-                        },
-                    )
                 ],
             }
         )

content/developer/howtos/rdtraining/B_acl_irrules.rst

@@ -10,8 +10,9 @@ Advanced B: ACL and Record Rules
     <howto/rdtraining>`.
 
     To follow the exercise, it is recommended that you fetch the branch
-    14.0-core from the repository XXX, it
+    15.0-core from the
-    contains a version of the module created during the core training we can use
+    `technical training solutions <https://github.com/odoo/technical-training-solutions/tree/15.0-core>`__ repository.
+    It contains a version of the module created during the core training we can use
     as a starting point.
 
 So far we have mostly concerned ourselves with implementing useful features.
@@ -223,7 +224,7 @@ individual records:
         <field name="name">A description of the rule's role</field>
         <field name="model_id" ref="model_to_manage"/>
         <field name="perm_read" eval="False"/>
-        <field name="groups" eval="[(4, ref('base.group_user'))]"/>
+        <field name="groups" eval="[Command.link(ref('base.group_user'))]"/>
         <field name="domain_force">[
             '|', ('user_id', '=', user.id),
                  ('user_id', '=', False)

content/developer/howtos/rdtraining/C_data.rst

@@ -6,7 +6,8 @@ Advanced C: Master and Demo Data
 
 .. tip:: This tutorial assumes you followed the Core Training.
 
-  To do the exercise, fetch the branch 14.0-core from the repository XXX.
+  To do the exercise, fetch the branch 15.0-core from the
+  `technical training solutions <https://github.com/odoo/technical-training-solutions/tree/15.0-core>`__ repository.
   It contains a basic module we will use as a starting point
 
 Data Types
@@ -303,23 +304,23 @@ Add X2many fields
 -----------------
 
 **Reference**: the documentation related to this topic can be found in
-:ref:`Common ORM methods<reference/orm/models/crud>`.
+:class:`~odoo.fields.Command`.
 
 If you need to add related data in a One2many or a Many2many field, you can do so by using the
-common ORM methods.
+:class:`~odoo.fields.Command` methods.
 
 .. code-block:: xml
 
     <odoo>
       <record id="id1" model="tutorial.example">
         <field name="related_ids" eval="[
-            (0, 0, {
+            Command.create({
                 'name': 'My name',
             }),
-            (0, 0, {
+            Command.create({
                 'name': 'Your name',
             }),
-            (4, ref('model.xml_id')),
+            Command.link(ref('model.xml_id')),
         ]"/>
       </record>
     </odoo>

content/developer/howtos/rdtraining/E_unittest.rst

@@ -6,7 +6,8 @@ Advanced E: Python Unit Tests
 
 .. tip:: This tutorial assumes you followed the Core Training.
 
-  To do the exercise, fetch the branch 14.0-core from the repository XXX.
+  To do the exercise, fetch the branch 15.0-core from the
+  `technical training solutions <https://github.com/odoo/technical-training-solutions/tree/15.0-core>`__ repository.
   It contains a basic module we will use as a starting point
 
 **Reference**:
@@ -175,18 +176,18 @@ coming from modules your module doesn't depend on.
 
 .. code-block:: python
 
-  from odoo.tests.common import SavepointCase
+  from odoo.tests.common import TransactionCase
   from odoo.tests import tagged
 
   # The CI will run these tests after all the modules are installed,
   # not right after installing the one defining it.
   @tagged('post_install', '-at_install')  # add `post_install` and remove `at_install`
-  class PostInstallTestCase(SavepointCase):
+  class PostInstallTestCase(TransactionCase):
       def test_01(self):
           ...
 
   @tagged('at_install')  # this is the default
-  class AtInstallTestCase(SavepointCase):
+  class AtInstallTestCase(TransactionCase):
       def test_01(self):
           ...
 
@@ -233,12 +234,7 @@ import the test folder/module in the ``__init__.py`` of the module.
   ├── __init__.py
   └── __manifest__.py
 
-.. note:: Some older tests extend ``odoo.tests.common.TransactionCase``, but they are less
+All the tests should extend ``odoo.tests.common.TransactionCase``. You usually define a
-  scalable. The difference is that the setup is done per test method and not per test class.
-  Changed data is rolled back between each test in `SavepointCase` to have the same behavior as
-  `TransactionCase`.
-
-All the tests should extend ``odoo.tests.common.SavepointCase``. You usually define a
 ``setUpClass`` and the tests. After writing the `setUpClass`, you have an `env` available in the
 class and can start interacting with the ORM.
 
@@ -246,14 +242,14 @@ These test classes are built on top of the ``unittest`` python module.
 
 .. code-block:: python
 
-  from odoo.tests.common import SavepointCase
+  from odoo.tests.common import TransactionCase
   from odoo.exceptions import UserError
   from odoo.tests import tagged
 
   # The CI will run these tests after all the modules are installed,
   # not right after installing the one defining it.
   @tagged('post_install', '-at_install')
-  class EstateTestCase(SavepointCase):
+  class EstateTestCase(TransactionCase):
 
       @classmethod
       def setUpClass(cls):

content/developer/howtos/rdtraining/J_reports.rst

@@ -10,8 +10,9 @@ Advanced J: PDF Reports
     and have installed :ref:`wkhtmltopdf <howto/rdtraining/02_setup/install-wkhtmltopdf>`.
 
     To follow the exercise, it is recommended that you fetch the branch
-    14.0-core from the repository XXX, it
+    15.0-core from the
-    contains a version of the module created during the core training we can use
+    `technical training solutions <https://github.com/odoo/technical-training-solutions/tree/15.0-core>`__ repository.
+    It contains a version of the module created during the core training we can use
     as a starting point.
 
 We were previously :ref:`introduced to QWeb <howto/rdtraining/15_qwebintro>`
@@ -95,9 +96,9 @@ If you don't have a set of data like this already, you can either:
 * Complete :ref:`howto/rdtraining/C_data` (if you haven't done so already) and add the extra
   cases to your demo data (you may need to create a new database to load in the demo data).
 * Manually create the data in your database.
-* Copy this `data file <https://github.com/odoo/technical-training-solutions/blob/14.0-J_reports/estate/data/estate_demo.xml>`__
+* Copy this `data file <https://github.com/odoo/technical-training-solutions/blob/15.0-J_reports/estate/data/estate_demo.xml>`__
   into a new directory (data) in your estate module and copy
-  `these lines <https://github.com/odoo/technical-training-solutions/blob/14.0-J_reports/estate/__manifest__.py#L21-L23>`__
+  `these lines <https://github.com/odoo/technical-training-solutions/blob/15.0-J_reports/estate/__manifest__.py#L21-L23>`__
   into your __manifest__.py file (you may need to create a new database to load in the demo data).
 
 Before continuing, click through your data in your database and make sure your data is as expected.

content/developer/howtos/rdtraining/K_dashboard.rst

@@ -10,8 +10,9 @@ Advanced K: Dashboards
     access to Odoo Enterprise features.
 
     To follow the exercise, it is recommended that you fetch the branch
-    14.0-core from the repository XXX, it
+    15.0-core from the
-    contains a version of the module created during the core training we can use
+    `technical training solutions <https://github.com/odoo/technical-training-solutions/tree/15.0-core>`__ repository.
+    It contains a version of the module created during the core training we can use
     as a starting point.
 
 The term "Dashboard" is used in Odoo for objects that display data, but involves different
@@ -118,9 +119,9 @@ If you don't have a set of data like this already, you can either:
 * Complete :ref:`howto/rdtraining/C_data` (if you haven't done so already) and add the extra
   cases to your demo data (you may need to create a new database to load in the demo data).
 * Manually create the data in your database.
-* Copy this `data file <https://github.com/odoo/technical-training-solutions/blob/14.0-K_dashboard/estate/data/estate_demo.xml>`__
+* Copy this `data file <https://github.com/odoo/technical-training-solutions/blob/15.0-K_dashboard/estate/data/estate_demo.xml>`__
   into a new directory called ``data`` in your estate module and copy
-  `these lines <https://github.com/odoo/technical-training-solutions/blob/14.0-K_dashboard/estate/__manifest__.py#L21-L23>`__
+  `these lines <https://github.com/odoo/technical-training-solutions/blob/15.0-K_dashboard/estate/__manifest__.py#L21-L23>`__
   into your __manifest__.py file (you may need to create a new database to load in the demo data).
 
 Click through your database data and make sure it is what you expect. Of course you can add the
@@ -208,7 +209,7 @@ no xml id is provided for a graph or pivot view then the default view will be us
 The cohort view will not work in the dashboard without a specific xml id. If you have already
 created some of these views then you are welcome to add them to your dashboard! Sample graph and
 pivot views are included in the
-`solution code <https://github.com/odoo/technical-training-solutions/blob/14.0-K_dashboard/estate/views/estate_property_views.xml#L169-L191>`__
+`solution code <https://github.com/odoo/technical-training-solutions/blob/15.0-K_dashboard/estate/views/estate_property_views.xml#L169-L191>`__
 that you are welcome to use as well.
 
 .. exercise:: Add subviews.

content/developer/reference/addons/orm.rst

@@ -611,7 +611,7 @@ Method decorators
 =================
 
 .. automodule:: odoo.api
-    :members: depends, depends_context, constrains, onchange, returns, autovacuum, model, model_create_multi
+    :members: depends, depends_context, constrains, onchange, returns, autovacuum, model, model_create_multi, ondelete
 
 .. .. currentmodule:: odoo.api