diff --git a/content/developer/howtos/rdtraining/01_architecture.rst b/content/developer/howtos/rdtraining/01_architecture.rst
index 76be120e1..85d54c053 100644
--- a/content/developer/howtos/rdtraining/01_architecture.rst
+++ b/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
 ============
 
diff --git a/content/developer/howtos/rdtraining/13_inheritance.rst b/content/developer/howtos/rdtraining/13_inheritance.rst
index 311f9f4bf..79645ab45 100644
--- a/content/developer/howtos/rdtraining/13_inheritance.rst
+++ b/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
-    with more than one record.
+    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.
diff --git a/content/developer/howtos/rdtraining/14_other_module.rst b/content/developer/howtos/rdtraining/14_other_module.rst
index 5473a2426..de0351147 100644
--- a/content/developer/howtos/rdtraining/14_other_module.rst
+++ b/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
-:ref:`reference/orm/models/crud`. This format is a list of triplets executed sequentially, where
-each triplet is a command to execute on the set of records. Here is a simple example to include
-a One2many field ``line_ids`` at creation of a ``test.model``:: 
+: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": [
-                    (
-                        0,
-                        0,
-                        {
-                            "field_1": "value_1",
-                            "field_2": "value_2",
-                        },
-                    )
+                    Command.create({
+                        "field_1": "value_1",
+                        "field_2": "value_2",
+                    })
                 ],
             }
         )
diff --git a/content/developer/howtos/rdtraining/B_acl_irrules.rst b/content/developer/howtos/rdtraining/B_acl_irrules.rst
index a30732d67..cc9e6dd7d 100644
--- a/content/developer/howtos/rdtraining/B_acl_irrules.rst
+++ b/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
-    contains a version of the module created during the core training we can use
+    15.0-core from the
+    `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)
diff --git a/content/developer/howtos/rdtraining/C_data.rst b/content/developer/howtos/rdtraining/C_data.rst
index 63ab2ae26..691aa33c1 100644
--- a/content/developer/howtos/rdtraining/C_data.rst
+++ b/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>
diff --git a/content/developer/howtos/rdtraining/E_unittest.rst b/content/developer/howtos/rdtraining/E_unittest.rst
index e53084537..90f4c398f 100644
--- a/content/developer/howtos/rdtraining/E_unittest.rst
+++ b/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
-  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
+All the tests should extend ``odoo.tests.common.TransactionCase``. 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):
diff --git a/content/developer/howtos/rdtraining/J_reports.rst b/content/developer/howtos/rdtraining/J_reports.rst
index 368b3442a..d87f53a01 100644
--- a/content/developer/howtos/rdtraining/J_reports.rst
+++ b/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
-    contains a version of the module created during the core training we can use
+    15.0-core from the
+    `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.
diff --git a/content/developer/howtos/rdtraining/K_dashboard.rst b/content/developer/howtos/rdtraining/K_dashboard.rst
index 0006c0316..29a79e7fa 100644
--- a/content/developer/howtos/rdtraining/K_dashboard.rst
+++ b/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
-    contains a version of the module created during the core training we can use
+    15.0-core from the
+    `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.
diff --git a/content/developer/reference/addons/orm.rst b/content/developer/reference/addons/orm.rst
index a02169367..dc00e6dfb 100644
--- a/content/developer/reference/addons/orm.rst
+++ b/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