[IMP] tests: make post_install the default

closes odoo/documentation#7573

X-original-commit: 93b47e7896
Signed-off-by: John Holton (hojo) <hojo@odoo.com>
Signed-off-by: Zachary Straub (zst) <zst@odoo.com>

content/applications/finance/accounting/bank/reconciliation.rst

@@ -53,7 +53,7 @@ Resulting entry
    The resulting entry section on the top right displays the selected bank transaction matched with
    the counterpart entries and includes any remaining debits or credits. In this section, you can
    validate the reconciliation or mark it as :guilabel:`To Check`. Any :ref:`reconciliation model
-   buttons <reconciliation_models_button>` are also available in the resulting entry section.
+   buttons <reconciliation/button>` are also available in the resulting entry section.
 
 Reconcile transactions
 ======================
@@ -62,13 +62,13 @@ Transactions can be matched automatically with the use of :doc:`reconciliation m
 <reconciliation_models>`, or they can be matched with :ref:`existing entries
 <reconciliation/existing-entries>`, :ref:`batch payments <reconciliation/batch-payments>`,
 :ref:`manual operations <reconciliation/manual-operations>`, and :ref:`reconciliation model buttons
-<reconciliation_models_button>`.
+<reconciliation/button>`.
 
 #. Select a transaction among unmatched bank transactions.
 #. Define the counterpart. There are several options for defining a counterpart, including
    :ref:`matching existing entries <reconciliation/existing-entries>`, :ref:`manual operations
    <reconciliation/manual-operations>`, :ref:`batch payments <reconciliation/batch-payments>`, and
-   :ref:`reconciliation model buttons <reconciliation_models_button>`.
+   :ref:`reconciliation model buttons <reconciliation/button>`.
 #. If the resulting entry is not fully balanced, balance it by adding another existing counterpart
    entry or writing it off with a :ref:`manual operation <reconciliation/manual-operations>`.
 #. Click the :guilabel:`Validate` button to confirm the reconciliation and move to the next
@@ -90,8 +90,8 @@ Match existing entries
 ----------------------
 
 This tab contains matching entries Odoo automatically pre-selects according to the reconciliation
-models. The entry order is based on :ref:`reconciliation models <reconciliation_models_suggestion>`,
-with suggested entries appearing first.
+models. The entry order is based on :doc:`reconciliation models <reconciliation_models>`, with
+suggested entries appearing first.
 
 .. tip::
    The search bar within the :guilabel:`Match Existing Entries` tab allows you to search for
@@ -130,10 +130,11 @@ of the relevant optional fields.
    .. image:: reconciliation/fully-paid.png
       :alt: Click on fully paid to manually set an invoice as entirely paid.
 
+.. _reconciliation/button:
 
 Reconciliation model buttons
 ----------------------------
 
-Use a :ref:`reconciliation model button <reconciliation_models_button>` for manual operations that
-are frequently used. These custom buttons allow you to quickly reconcile bank transactions manually
-and can also be used in combination with existing entries.
+Use a :doc:`reconciliation model <reconciliation_models>` button for manual operations that are
+frequently used. These custom buttons allow you to quickly reconcile bank transactions manually and
+can also be used in combination with existing entries.

content/applications/finance/accounting/bank/reconciliation_models.rst

@@ -1,129 +1,123 @@
 =====================
-Reconciliation Models
+Reconciliation models
 =====================
 
-Once the bank statements are correctly imported, it is essential to *reconcile* the records properly
-and ensure all *Journal Entries* are balanced and in agreement. To ease and speed up the
-reconciliation process, you can configure **Reconciliation Models**, which are particularly useful
-with recurrent entries such as bank fees.
+Reconciliation models are used to automate the :doc:`bank reconciliation <reconciliation>` process,
+which is especially handy when dealing with recurring entries like bank fees. Reconciliation models
+can also be helpful in handling :doc:`cash discounts <../customer_invoices/cash_discounts>`.
 
-.. todo:: Add a link to the Reconciliation process in the paragraph above, once the doc will have
-   been updated.
-
-.. note::
-   Reconciliation Models are also useful to handle *Cash Discounts*. Please refer to
-   :doc:`this documentation <../customer_invoices/cash_discounts>` for more
-   information.
-
-.. _reconciliation_models_types:
-
-Types of Reconciliation Models
-==============================
-
-There are three types of Reconciliation Models:
-
-#. :ref:`Write-off Button <reconciliation_models_button>`
-#. :ref:`Suggestion of counterpart values <reconciliation_models_suggestion>`
-#. :ref:`Match existing invoices/bills <reconciliation_models_match>`
-
-.. _reconciliation_models_button:
-
-Manually create a write-off on clicked button
----------------------------------------------
-
-When you are reconciling an entry with an *Open Balance*, you can use the buttons available under
-the *Manual Operations* tab to pre-fill all the values automatically, before validating the
-reconciliation. Each button is a different Reconciliation Model.
-
-.. image:: reconciliation_models/reconciliation_models_button.png
-   :align: center
-   :alt: Example of a Reconciliation Model with a write-off button in Odoo Accounting
-
-.. _reconciliation_models_suggestion:
-
-Suggest counterpart values
---------------------------
-
-This type of Reconciliation Model suggests immediately counterpart values that only need to be
-validated. This automation is based on a set of rules defined in the reconciliation model.
-
-.. image:: reconciliation_models/reconciliation_models_suggestion.png
-   :align: center
-   :alt: Example of a Reconciliation Model that suggests counterpart values in Odoo Accounting
-
-.. _reconciliation_models_match:
-
-Match existing invoices/bills
------------------------------
-
-This type of Reconciliation Model automatically selects the right Customer Invoice or Vendor Bill
-that matches the payment. All that is left to do is to validate the entry. This automation is based
-on a set of rules defined in the reconciliation model.
-
-.. image:: reconciliation_models/reconciliation_models_match.png
-   :align: center
-   :alt: Example of a Reconciliation Model that matches existing invoices and bills automatically
-         in Odoo Accounting
-
-Configuration
-=============
-
-To manage or create new **Reconciliation Models**, go to :menuselection:`Accounting -->
-Reconciliation --> Reconciliation Models`. Alternatively, you can also open this menu from the
-Accounting Overview, by going to your Bank Journal card, clicking on the three little dots, and then
-on *Reconciliation Models*.
-
-.. image:: reconciliation_models/reconciliation_models_overview.png
-   :align: center
-   :alt: Open the Reconciliation Model menu from the overview dashboard in Odoo Accounting
-
-.. important::
-   The first entry, named *Invoices Matching Rule*, is the one responsible for the current matching
-   of invoices and bills. Therefore, it is advised to leave it at the top of the list and not to
-   delete it.
-
-Open the model you want to modify, or click on *Create* to create a new one, then fill out the form.
-
-Type
-----
-
-See :ref:`above <reconciliation_models_types>` for an explanation about the different types of
-Reconciliation Models.
-
-.. note::
-   If the *Documents* application is installed on your database, an additional **Activity type**
-   field appears when *To check* is ticked. Selecting the value *Reconciliation request* implies
-   that, whenever you use this model, a *Request Document* window pops up to request a document from
-   a user.
-
-Conditions on Bank Statement Line
----------------------------------
-
-Define here all the conditions that are required for a Reconciliation Model to be applied.
-
-.. important::
-   If a record matches with several Reconciliation Models, the first one in the *sequence* of models
-   will be applied. The sequence is simply the order of the models in the *list view*. They can be
-   rearranged by dragging-and-dropping the handle next to the name.
-
-.. image:: reconciliation_models/reconciliation_models_conditions.png
-   :align: center
-   :alt: Conditions for the Reconciliation Model to be applied in Odoo Accounting
-
-Counterpart Values
-------------------
-
-This section comprises the values that are applied by the Reconciliation Model.
-
-If the value to reconcile needs to be written-off in two separate accounts, click on *Add a second
-line*.
-
-.. image:: reconciliation_models/reconciliation_models_counterparts.png
-   :align: center
-   :alt: Counterparts values of a Reconciliation Model in Odoo Accounting
+Each model is created based on a :ref:`model type <models/type>` and :guilabel:`bank transaction
+conditions`.
 
 .. seealso::
-
-   - :doc:`reconciliation`
    - :doc:`bank_synchronization`
-   - :doc:`../customer_invoices/cash_discounts`
+   - `Odoo Tutorials: Reconciliation models <https://www.odoo.com/slides/slide/reconciliation-models-1841?fullscreen=1>`_
+
+.. _models/type:
+
+Reconciliation model types
+==========================
+
+The reconciliation models are available by going to :menuselection:`Accounting --> Configuration
+--> Banks: Reconciliation Models`. For each reconciliation model, a :guilabel:`Type` must be set.
+Three types of models exist:
+
+- :guilabel:`Button to generate counterpart entry`: a button is created in the resulting entry
+  section of the bank reconciliation view. If clicked, this button generates a counterpart entry to
+  reconcile with the active transaction based on the rules set in the model. The rules specified in
+  the model determine the counterpart entry's account(s), amount(s), label(s), and analytic
+  distribution;
+- :guilabel:`Rule to suggest counterpart entry`: used for recurring transactions to match the
+  transaction to a new entry based on conditions that must match the information on the transaction;
+- :guilabel:`Rule to match invoices/bills`: used for recurring transactions to match the transaction
+  to existing invoices, bills, or payments based on conditions that must match the information on
+  the transaction.
+
+Default reconciliation models
+=============================
+
+In Odoo, different models are available by default depending on the company's fiscal localization.
+These can be updated if needed. Users can also create their own reconciliation models by clicking
+:guilabel:`New`.
+
+.. important::
+   If a record matches with several reconciliation models, the first one in the *sequence* of models
+   is applied. You can rearrange the order by dragging and dropping the handle next to the name.
+
+   .. image:: reconciliation_models/list-view.png
+      :alt: Rearrange the sequence of models in the list view.
+
+Invoices/Bills perfect match
+----------------------------
+
+This model should be at the top of the *sequence* of models, as it enables Odoo to suggest matching
+existing invoices or bills with a bank transaction based on set conditions.
+
+.. image:: reconciliation_models/invoices-bills-perfect-match.png
+   :alt: Set rules to trigger the reconciliation.
+
+Odoo automatically reconciles the payment when the :guilabel:`Auto-validate` option is selected, and
+the model conditions are perfectly met. In this case, it expects to find on the bank statement's
+line the invoice/payment's reference (as :guilabel:`Label` is selected) and the partner's name
+(as :guilabel:`Partner is set` is selected) to suggest the correct counterpart entry and reconcile
+the payment automatically.
+
+Invoices/Bills partial match if underpaid
+-----------------------------------------
+
+This model suggests a customer invoice or vendor bill that partially matches the payment when the
+amount received is slightly lower than the invoice amount, for example in the case of
+**cash discounts**. The difference is reconciled with the account indicated in the
+:guilabel:`counterpart entries` tab.
+
+The reconciliation model :guilabel:`Type` is :guilabel:`Rule to match invoices/bills`, and the
+:guilabel:`Payment tolerance` should be set.
+
+.. image:: reconciliation_models/partial-match.png
+   :alt: Set rules to trigger the reconciliation.
+
+.. note::
+   The :guilabel:`Payment tolerance` is only applicable to lower payments. It is disregarded when an
+   overpayment is received.
+
+.. seealso::
+   :doc:`../customer_invoices/cash_discounts`
+
+Line with bank fees
+-------------------
+
+This model suggests a counterpart entry according to the rules set in the model. In this case, the
+reconciliation model :guilabel:`Type` is :guilabel:`Rule to suggest counterpart entry`, and the
+:guilabel:`Label` can be used for example, to identify the information referring to the
+:guilabel:`Bank fees` in the label of the transaction.
+
+.. image:: reconciliation_models/bank-fees.png
+   :alt: Set rules to trigger the reconciliation.
+
+.. note::
+   `Regular expressions <https://regexone.com/>`_, often abbreviated as **Regex**, can be used in
+   Odoo in various ways to search, validate, and manipulate data within the system. Regex can be
+   powerful but also complex, so it's essential to use it judiciously and with a good understanding
+   of the patterns you're working with.
+
+   To use regular expressions in your reconciliation models, set the :guilabel:`Transaction Type`
+   to :guilabel:`Match Regex` and add your expression. Odoo automatically retrieves the
+   transactions that match your Regex expression and the conditions specified in your model.
+
+   .. image:: reconciliation_models/regex.png
+      :alt: Using Regex in Odoo
+
+Partner mapping
+===============
+
+Partner mapping allows you to establish rules for automatically matching transactions to the correct
+partner account, saving time and reducing the risk of errors that can occur during manual
+reconciliation. For example, you can create a partner mapping rule for incoming payments with
+specific reference numbers or keywords in the transaction description. When an incoming payment
+meets these criteria, Odoo automatically maps it to the corresponding customer's account.
+
+To create a partner mapping rule, go to the :guilabel:`Partner Mapping` tab and enter the
+:guilabel:`Find Text in Label`, :guilabel:`Find Text in Notes`, and :guilabel:`Partner`.
+
+.. image:: reconciliation_models/partner-mapping.png
+   :alt: defining partner mapping

content/applications/general/in_app_purchase.rst

@@ -1,59 +1,192 @@
 =====================
-In-App Purchase (IAP)
+In-app purchase (IAP)
 =====================
 
-In-App Purchases (IAP) gives access to additional services through Odoo. For instance, it allows you
-to send SMS Text Messages or to send Invoices by post directly from your database.
+.. |IAP| replace:: :abbr:`IAP (In-app purchases)`
+
+In-app purchases (IAP) are optional services that enhance Odoo databases. Each service provides its
+own specific features and functionality. A full list of services is available on the `Odoo IAP
+Catalog <https://iap.odoo.com/iap/all-in-app-services>`_.
+
+.. image:: in_app_purchase/iap.png
+   :align: center
+   :alt: The IAP catalog with various services available on IAP.Odoo.com.
+
+.. example::
+   The :guilabel:`SMS` service sends text messages to contacts directly from the database, and the
+   :guilabel:`Documents Digitization` service digitizes scanned or PDF vendor bills, expenses, and
+   resumes with optical character recognition (OCR) and artificial intelligence (AI).
+
+|IAP| services do **not** need to be configured or set up before use. Odoo users can simply click on
+the service in the app to activate it. However, each service requires its own prepaid credits, and
+when they run out, users **must** :ref:`buy more <iap/buying_credits>` in order to keep using it.
+
+.. note::
+   Users with an Enterprise version of Odoo Online get free credits to test IAP features.
+
+.. _in_app_purchase/portal:
+
+IAP services
+============
+
+|IAP| services are provided by Odoo, as well as third-parties, and have a wide range of uses.
+
+The following |IAP| services are provided by Odoo:
+
+- :guilabel:`Documents Digitization`: digitizes scanned or PDF vendor bills, expenses, and resumes
+  with OCR and AI.
+- :guilabel:`Partner Autocomplete`: automatically populates contact records with corporate data.
+- :guilabel:`SMS`: sends SMS text messages to contacts directly from the database.
+- :guilabel:`Lead Generation`: generates leads based on a set of criteria, and converts web visitors
+  into quality leads and opportunities.
+- :guilabel:`Snailmail`: sends customer invoices and follow-up reports by post, worldwide.
+
+For more information on every service currently available, visit the `Odoo IAP Catalog
+<https://iap.odoo.com/iap/all-in-app-services>`_.
+
+Use IAP services
+----------------
+
+|IAP| services are automatically integrated with Odoo, and do **not** require users to configure any
+settings. To use a service, simply interact with it wherever it appears in the database.
+
+.. example::
+   The following flow focuses on the *SMS* |IAP| service being used from a contact's record.
+
+   This can be done by clicking the :guilabel:`📱 (phone) SMS` icon within the database.
+
+   .. image:: in_app_purchase/sms-icon.png
+      :align: center
+      :alt: The SMS icon on a typical contact information form located within an Odoo database.
+
+   One way to utilize the *SMS* |IAP| service with Odoo is showcased in the following steps:
+
+   #. Navigate to the :menuselection:`Contacts application`, and click on a contact with a mobile
+      phone number entered in either the :guilabel:`Phone` or :guilabel:`Mobile` field of the
+      contact form.
+   #. Hover the mouse over the :guilabel:`Phone` or :guilabel:`Mobile` field, and a :guilabel:`📱
+      (phone) SMS` icon appears to the right.
+   #. Click the :guilabel:`📱 (phone) SMS` icon, and a :guilabel:`Send SMS Text Message` pop-up
+      window appears.
+   #. Type a message in the :guilabel:`Message` field of the :guilabel:`Send SMS Text Message`
+      pop-up window. Then, click the :guilabel:`Send SMS` button. Odoo then sends the message, via
+      SMS, to the contact, and logs what was sent in the *chatter* of the contact's form.
+
+   Upon sending the SMS message, the prepaid credits for the *SMS* |IAP| service are automatically
+   deducted from the existing credits. If there are not enough credits to send the message, Odoo
+   prompts the user to purchase more.
+
+.. seealso::
+   For more information on how to use various |IAP| services, and for more in-depth instructions
+   related to SMS functionality in Odoo, review the documentation below:
+
+   - :doc:`Lead mining </applications/sales/crm/acquire_leads/lead_mining>`
+   - :doc:`Enrich your contacts base with Partner Autocomplete
+     </applications/sales/crm/optimize/partner_autocomplete>`
+   - :doc:`SMS essentials </applications/marketing/sms_marketing/essentials/sms_essentials>`
+
+.. _in_app_purchase/credits:
+
+IAP credits
+===========
+
+Every time an |IAP| service is used, the prepaid credits for that service are spent. Odoo prompts
+the purchase of more credits when there are not enough credits left to continue using a service.
+Email alerts can also be set up for when :ref:`credits are low <in_app_purchase/low-credits>`.
+
+Credits are purchased in *Packs* from the `Odoo IAP Catalog
+<https://iap.odoo.com/iap/all-in-app-services>`_, and pricing is specific to each service.
+
+.. example::
+   The `SMS service <https://iap.odoo.com/iap/in-app-services/1>`_ has four packs available, in
+   denominations of:
+
+   - :guilabel:`Starter Pack`: 10 credits
+   - :guilabel:`Standard Pack`: 100 credits
+   - :guilabel:`Advanced Pack`: 500 credits
+   - :guilabel:`Expert Pack`: 1,000 credits
+
+   .. image:: in_app_purchase/packs.png
+      :align: center
+      :alt: Four different packs of credits for the SMS IAP service.
+
+   The number of credits consumed depends on the length of the SMS and the country of destination.
+
+   For more information, refer to the :doc:`SMS Pricing and FAQ
+   </applications/marketing/sms_marketing/pricing/pricing_and_faq>` documentation.
 
 .. _iap/buying_credits:
 
-Buying Credits
-==============
+Buy credits
+-----------
 
-Each IAP Service relies on prepaid credits to work and has its own pricing. To consult your current
-balance or to recharge your account, go to :menuselection:`Settings --> Odoo IAP --> View my
-Services`.
+If there are not enough credits to perform a task, the database automatically prompts the purchase
+of more credits.
 
-.. image:: in_app_purchase/image1.png
-   :align: center
+Users can check the current balance of credits for each service, and manually purchase more credits,
+by navigating to the :menuselection:`Settings app --> Search IAP --> View My Services`.
 
-.. tip::
-   If you are on Odoo Online and have the Enterprise version, you benefit from free credits to test our
-   IAP features.
+Doing so reveals an :guilabel:`IAP Account` page, listing the various |IAP| services in the
+database. From here, click an |IAP| service to open its :guilabel:`Account Information` page, where
+additional credits can be purchased.
 
-IAP accounts
-============
+Manually buy credits
+~~~~~~~~~~~~~~~~~~~~
 
-Credits to use IAP services are stored on IAP accounts, which are specific to each service.
-By default, IAP accounts are common to all companies, but can be restricted to specific
-ones. Activate the :ref:`developer mode <developer-mode>`, then go to :menuselection:`Technical
-Settings --> IAP Account`.
+To manually buy credits in Odoo, follow these steps:
 
-.. image:: in_app_purchase/image2.png
-   :align: center
+#. Go to the :menuselection:`Settings application`.
+#. Type `IAP` in the search bar.
+#. Click :guilabel:`View My Services`.
 
-.. tip::
-   An IAP account can be disabled by appending `+disabled` to its token.
-   Reverting this change will re-enable the account.
+   .. image:: in_app_purchase/view-services.png
+      :align: center
+      :alt: The Settings app showing the Odoo IAP heading and View My Services button.
 
-IAP Portal
-==========
+#. Doing so reveals an :guilabel:`IAP Account` page, listing the various |IAP| services in the
+   database. From here, click an |IAP| service to open its :guilabel:`Account Information` page,
+   where additional credits can be purchased.
+#. On the :guilabel:`Account Information` page, click the :guilabel:`Buy Credit` button.
 
-The IAP Portal is a platform regrouping your IAP Services. It is accessible from
-:menuselection:`Settings app --> Odoo IAP --> View my Services`. From there, you can view your current
-balance, recharge your credits and set a reminder when your balance falls below a threshold.
+   .. image:: in_app_purchase/account-info.png
+      :align: center
+      :alt: The Account Information page for an IAP service showing the Buy Credit button.
 
-.. image:: in_app_purchase/image3.png
-   :align: center
+#. Doing so loads a :guilabel:`Buy Credits for (IAP Account)` page in a new tab. From here, click
+   :guilabel:`Buy` on the desired pack of credits. Then, follow the prompts to enter payment
+   details, and confirm the order.
 
-Get notified when credits are low
-=================================
+   .. image:: in_app_purchase/buy-pack.png
+      :align: center
+      :alt: The SMS service page on IAP.Odoo.com with four packs of credits available for purchase.
 
-To be notified when it’s time to recharge your credits, you can go to your IAP Portal through
-:menuselection:`Settings app --> Odoo IAP --> View my Services`, unfold a service and check the
-Receive threshold warning option. Then, you can provide a minimum amount of credits and email
-addresses. Now, every time that the limit is reached, an automatic reminder will be sent by
-email!
+#. Once the transaction is complete, the credits are available for use in the database.
 
-.. image:: in_app_purchase/image4.png
-   :align: center
+.. _in_app_purchase/low-credits:
+
+Low-credit notification
+~~~~~~~~~~~~~~~~~~~~~~~
+
+It is possible to be notified when credits are low, in order to avoid running out of credits, while
+using an |IAP| service. To do that, follow this process:
+
+#. Go to the :menuselection:`Settings application`.
+#. Type `IAP` in the search bar.
+#. Click :guilabel:`View My Services`.
+#. The available |IAP| accounts appear in a list view on the :guilabel:`IAP Account` page. From
+   here, click on the desired |IAP| account to view that service's :guilabel:`Account Information`
+   page.
+#. On the :guilabel:`Account Information` page, tick the :guilabel:`Warn Me` box. Doing so reveals
+   two fields on the form: :guilabel:`Threshold` and :guilabel:`Warning Email`.
+
+   .. image:: in_app_purchase/low-credits.png
+      :align: center
+      :alt: Odoo will send an email alert when credits for this service fall below the threshold.
+
+#. In the :guilabel:`Threshold` field, enter an amount of credits Odoo should use as the minimum
+   threshold for this service.
+#. In the :guilabel:`Warning Email` field, enter the email address that should receive the
+   notification.
+
+Odoo sends a low-credit alert to the :guilabel:`Warning Email` when the balance of credits falls
+below the amount listed as the :guilabel:`Threshold`.

content/applications/hr.rst

@@ -10,5 +10,6 @@ Human resources
    hr/employees
    hr/fleet
    hr/payroll
+   hr/time_off
    hr/recruitment
    hr/referrals

content/applications/hr/employees/new_employee.rst

@@ -193,6 +193,8 @@ types needed.
           :align: center
           :alt: A skill form for a Math skill type, with all the information entered.
 
+.. _employees/work-info-tab:
+
 Work Information tab
 --------------------
 

content/applications/hr/payroll.rst

@@ -159,6 +159,8 @@ Reporting section
    :align: center
    :alt: New work entry type form with all fields to be filled in.
 
+.. _payroll/working-times:
+
 Working schedules
 -----------------
 

content/applications/hr/time_off.rst

@@ -0,0 +1,745 @@
+========
+Time Off
+========
+
+Odoo's *Time Off* application is a centralized place, where all time off information is housed. The
+*Time Off* app manages everything related to requests, balances, allocations, approvals, and
+reports.
+
+Users can :ref:`request time off <time_off/request-time-off>`, managers can :ref:`approve time off
+requests <time_off/approve-time-off>`, :ref:`allocate time off <time_off/allocate>` to individuals,
+teams, or the whole company, :ref:`reports <time_off/reporting>` can be run to see how much time off
+(and what kinds of time off) are being used, :ref:`accrual plans <time_off/accrual-plans>` can be
+created, and :ref:`public holidays <time_off/public-holidays>` can be set.
+
+.. note::
+   Be advised, only users with specific access rights can see all aspects of the *Time Off*
+   application.
+
+   All users can access the :guilabel:`My Time Off` and :guilabel:`Overview` sections of the *Time
+   Off* application. All other sections require specific access rights.
+
+   To better understand how access rights affect the *Time Off* application, refer to the
+   :doc:`/applications/hr/employees/new_employee` document, specifically the section about
+   configuring the work information tab.
+
+Configuration
+=============
+
+In order to allocate time off to employees, and for employees to request and use their time off, the
+various time off types must be configured first, then allocated to employees (if allocation is
+required).
+
+.. _time_off/time-off-types:
+
+Time off types
+--------------
+
+To view the currently configured time off types, navigate to :menuselection:`Time Off application
+--> Configuration --> Time Off Types`. The time off types are presented in a list view. The *Time
+Off* application comes with four types of time off pre-configured: :guilabel:`Paid Time Off`,
+:guilabel:`Sick Time Off`, :guilabel:`Unpaid`, and :guilabel:`Compensatory Days`. Any of these may
+be modified to suit the needs of the businesses, or can be used as-is.
+
+Create time off type
+~~~~~~~~~~~~~~~~~~~~
+
+To create a new time off type, navigate to :menuselection:`Time Off app --> Configuration --> Time
+Off Types`. From here, click the :guilabel:`Create` button to reveal a blank time off type form.
+
+Enter the name for the particular type of time off in the blank line at the top of the form, such as
+`Sick Time` or `Vacation`. Then, enter the following information on the form:
+
+Time off requests section
+*************************
+
+- :guilabel:`Approval`: select what specific kind of approval is required for the time off type. The
+  options are:
+
+  - :guilabel:`No Validation`: no approvals are required when requesting this type of time off. The
+    time off request is automatically approved when requested.
+  - :guilabel:`By Time Off Officer`: only the specified :ref:`Time Off Officer
+    <time_off/time-off-officer>`, set on this form in the :guilabel:`Responsible Time Off Officer`
+    field, is required to approve the time off request. This option is selected by default.
+  - :guilabel:`By Employee's Approver`: only the employee's specified approver for time off, which
+    is set on the *Work Information* tab on the :ref:`employee's form <employees/work-info-tab>`, is
+    required to approve the time off request.
+  - :guilabel:`By Employee's Approver and Time Off Officer`: both the employee's :ref:`specified
+    time off approver<employees/work-info-tab>` and the :ref:`Time Off Officer
+    <time_off/time-off-officer>` are required to approve the time off request.
+
+  .. _`time_off/time-off-officer`:
+
+- :guilabel:`Responsible Time Off Officer`: select the person responsible for approving requests and
+  allocations for this specific type of time off.
+- :guilabel:`Take Time Off in`: select the format the time off is requested from the drop-down menu.
+  The options are:
+
+  - :guilabel:`Day`: if time off can only be requested in full day increments (8 hours).
+  - :guilabel:`Half Day`: if time off can only be requested in half day increments (4 hours).
+  - :guilabel:`Hours`: if the time off can be taken in hourly increments.
+
+- :guilabel:`Deduct Extra Hours`: tick this box if the time off request should factor in any extra
+  time accrued by the employee
+
+  .. example::
+     For example, if an employee worked two (2) extra hours for the week, and requests five (5)
+     hours of time off, the request would be for three (3) hours, since the two (2) additionally
+     worked hours are used first, and deducted from the request.
+
+- :guilabel:`Allow To Join Supporting Document`: tick this box to allow the employee to attach
+  documents to the time off request. This is useful in situations where documentation is required,
+  such as long-term medical leave.
+- :guilabel:`Kind of Leave`: select from the drop-down menu the type of leave this time off type is,
+  either :guilabel:`Time Off` or :guilabel:`Other`.
+- :guilabel:`Company`: if multiple companies are created in the database, and this time off type
+  only applies to one company, select the company from the drop-down menu. If this field is left
+  blank, the time off type applies to all companies in the database.
+
+Allocation requests section
+***************************
+
+- :guilabel:`Requires allocation`: if the time off must be allocated to employees, select
+  :guilabel:`Yes`. If the time off can be requested without time off being previously allocated,
+  select :guilabel:`No Limit`. If :guilabel:`No Limit` is selected, the following options do not
+  appear on the form.
+- :guilabel:`Employee Requests`: select :guilabel:`Extra Days Requests Allowed` if the employee is
+  able to request more time off than was allocated.
+
+  .. example::
+     For example, if ten (10) days are allocated to the employee for this particular type of time
+     off, and this option is enabled, the employee may submit a request for more than ten (10) days.
+
+  If employees should **not** be able to make requests for more time off than what was allocated,
+  select the :guilabel:`Not Allowed` option.
+
+- :guilabel:`Approval`: select the type of approval(s) required for the allocation of this
+  particular type of time off.
+
+  - :guilabel:`No validation needed` indicates that no approvals are required.
+  - :guilabel:`Approved by Time Off Officer` indicates the :ref:`Time Off Officer
+    <time_off/time-off-officer>` set on this form must approve the allocation.
+  - :guilabel:`Set by Time Off Officer` indicates that the :ref:`Time Off Officer
+    <time_off/time-off-officer>` set on this form must allocate the time off.
+
+Payroll section
+***************
+
+If the time off type should create :doc:`../hr/payroll/work_entries` in the *Payroll* application,
+select the :guilabel:`Work Entry Type` from the drop-down list.
+
+Timesheets section
+******************
+
+.. note::
+   The :guilabel:`Timesheets` section only appears if the user is in developer mode. Refer to the
+   :ref:`developer-mode` document for details on how to access the developer mode.
+
+When an employee takes time off and is also using timesheets, Odoo creates entries in the timesheet
+for the time off. This section defines how they are entered.
+
+- :guilabel:`Project`: select the project that the time off type entries appear in.
+- :guilabel:`Task`: select the task that appears in the timesheet for this time off type. The
+  options are: :guilabel:`Time Off`, :guilabel:`Meeting`, or :guilabel:`Training`.
+
+Display option section
+**********************
+
+- :guilabel:`Color`: select a color to be used in the *Time Off* application dashboard.
+- :guilabel:`Cover Image`: select an icon to be used in the *Time Off* application dashboard.
+
+.. note::
+   The only required fields on the time off type form are the name of the :guilabel:`Time Off Type`,
+   the :guilabel:`Approval`, the :guilabel:`Responsible Time Off Officer`, :guilabel:`Take Time Off
+   in`, :guilabel:`Kind of Leave`, and the :guilabel:`Allocation Requests` section.
+
+.. image:: time_off/time-off-type-form.png
+   :align: center
+   :alt: Time off type form with all the information filled out for sick time off.
+
+.. _time_off/accrual-plans:
+
+Accrual plans
+-------------
+
+Some time off is earned through an accrual plan, meaning that for every specified amount of time an
+employee works (hour, day, week, etc), they earn or *accrue* a specified amount of time off.
+
+.. example::
+   If an employee accrues a vacation day for every week they work, they would earn 0.2 vacation days
+   for each hour they work. At the end of a forty (40) hour work week, they earn a whole vacation
+   day (8 hours).
+
+Create accrual plan
+~~~~~~~~~~~~~~~~~~~
+
+To create a new accrual plan, navigate to :menuselection:`Time Off app --> Configuration --> Accrual
+Plans`. Then, click the :guilabel:`Create` button, which reveals a blank accrual plan form.
+
+Enter the accrual plan name in the :guilabel:`Name` field. If the accrual plan only applies to a
+specific time off type, select it from the drop-down menu. If this accrual plan is available for all
+time off types, leave this field blank.
+
+Next, select how the :guilabel:`Level Transition` occurs, either :guilabel:`Immediately` or
+:guilabel:`After this accrual's period`. By default, the first level begins once the time off is
+approved if the time off is based on an accrual plan. If :guilabel:`Immediately` is selected, then
+the next level begins according to the time frame set on the level. If :guilabel:`After this
+accrual's period` is selected, the next level does not begin until the first level is completed
+according to the rules set on it.
+
+Rules
+*****
+
+Rules must be created in order for the accrual plan to accrue time off.
+
+To create a new rule, click the :guilabel:`Add A New Level` button right beneath the word `Rules`,
+and a :guilabel:`Create Level` pop-up form appears.
+
+Fill out the following fields on the form:
+
+- :guilabel:`Start after (#) (time period) after allocation date`: enter the number and value of the
+  time period that must pass before the employee starts to accumulate time off. The first value is
+  numerical; enter a number in the first field.
+
+  Then, select the type of time period using the drop-down menu in the second field. The options
+  are: :guilabel:`day(s)`, :guilabel:`month(s)`, or :guilabel:`year(s)`.
+- :guilabel:`Based on worked time`: tick this box if the accrual of time off is based on the time
+  the employee has worked. If an employee takes time off that is *not* considered a worked day, Odoo
+  will not count that day towards their accrual plan.
+- :guilabel:`Rate (#) (time)`: enter the rate of time off that is accumulated. The first value is
+  numerical; enter a number in the first field. Whole numbers are not necessary, any decimal value
+  may be entered.
+
+  Next, in the second field, select the type of time accrued using the drop-down menu. The options
+  are either :guilabel:`Days` or :guilabel:`Hours`.
+- :guilabel:`Frequency (X)`: select how often the employee accrues the time off for this rule using
+  the drop-down menu. The options are :guilabel:`Daily`, :guilabel:`Weekly`, :guilabel:`Twice a
+  month`, :guilabel:`Monthly`, :guilabel:`Twice a year`, or :guilabel:`Yearly`.
+
+  Depending on the selection, more fields appear to specify exactly when the accrual renews.
+
+.. example::
+   If the employee should accrue one vacation day for every week worked, the :guilabel:`Rate` is set
+   to `1`, and the :guilabel:`Frequency` entry is set to `Frequency (Weekly) on (Friday)`. Only the
+   :guilabel:`Frequency` and :guilabel:`Weekday` fields appear.
+
+   If the employee should accrue ten (10)vacation days each year, and they receive these days every
+   year on the first of January, the :guilabel:`Rate` is set to `10`, and the :guilabel:`Frequency`
+   entry is set to `Frequency (Yearly) on the (1) of (January)`. The :guilabel:`Frequency`,
+   :guilabel:`Date`, and :guilabel:`Month` fields appear.
+
+- :guilabel:`Limit to`: enter a maximum amount of days the employee can accrue with this plan.
+- :guilabel:`At the end of the calendar year, unused accruals will be`: select from the drop-down
+  menu how unused time off is handled.
+
+  The options are either :guilabel:`Transferred to the next year`, which rolls over unused time to
+  the next calendar year, or :guilabel:`Lost`, which means any unused time off is gone.
+
+.. image:: time_off/new-level.png
+   :align: center
+   :alt: A level form with all the data filled out.
+
+When the form is filled out, click :guilabel:`Save & Close` to save the form and close the pop-up,
+or :guilabel:`Save & New` to save the form and create a new rule. Add as many levels as desired.
+
+.. image:: time_off/accrual-plan-form.png
+   :align: center
+   :alt: An accrual form with all the entries filled out.
+
+.. _time_off/public-holidays:
+
+Public holidays
+---------------
+
+Most countries have public or national holidays, and some companies may have specific days they are
+closed and/or give extra days as holidays.
+
+It is important to configure these days in Odoo, so employees are aware of the days they have off,
+and do not request time off on days that are already set as a public holiday (non-working days).
+
+Create public holiday
+~~~~~~~~~~~~~~~~~~~~~
+
+To create a public holiday, navigate to :menuselection:`Time Off app --> Configuration --> Public
+Holidays`.
+
+All currently configured public holidays appear in a list view.
+
+Click the :guilabel:`Create` button, and a new line appears at the bottom of the list.
+
+Enter the following information:
+
+- :guilabel:`Name`: enter the name of the holiday.
+- :guilabel:`Company`: if in a multi-company database, the current company populates this field by
+  default. It is not possible to edit this field.
+- :guilabel:`Start Date`: using the date and time picker, select the date and time that the holiday
+  starts. By default, this field is configured for the current date. The start time is set according
+  to the start time for the company (according to the :ref:`working times <payroll/working-times>`).
+  If the user's computer is set to a different time zone, the start time is adjusted according to
+  the difference in the time zone compared to the company's time zone.
+- :guilabel:`End Date`: using the date and time picker, select the date and time that the holiday
+  ends. By default, this field is configured for the current date, and the time is set to the end
+  time for the company (according to the :ref:`working times <payroll/working-times>`). If the
+  user's computer is set to a different time zone, the start time is adjusted according to the
+  difference in the time zone compared to the company's time zone.
+
+  .. example::
+     A company is located in San Francisco, and the working times are 9:00 AM - 6:00 PM (an eight
+     (8) hour work day with a one (1) hour lunch break). A user is located in New York, and their
+     computer time zone is set to Eastern. When they create a Public Holiday, the start time appears
+     as 12:00 PM - 9:00 PM, since the time zone is accounted for. If a different user is located in
+     Los Angeles, and their computer time zone is set to Pacific, when they create a Public Holiday,
+     the time appears as 9:00 AM - 6:00 PM.
+
+- :guilabel:`Working Hours`: if the holiday should only apply to employees who have a specific set
+  of working hours, select the working hours from the drop-down menu. If left blank, the holiday
+  applies to all employees.
+- :guilabel:`Work Entry Type`: if using the *Payroll* application, this field defines how the work
+  entry for the holiday appears. Select the work entry type from the drop-down menu.
+
+.. image:: time_off/holidays.png
+   :align: center
+   :alt: The list of public holidays in the configuration menu.
+
+.. _time_off/allocate:
+
+Overview
+========
+
+To view a color-coded schedule of both the user's time off, and/or the team managed by them,
+navigate to :menuselection:`Time Off app --> Overview`. This presents a calendar with the default
+filter of :guilabel:`My Team`, in a month view.
+
+To change the time period displayed, click on either the :guilabel:`Day`, :guilabel:`Week`,
+:guilabel:`Month`, or :guilabel:`Year` buttons to present the calendar in that corresponding view.
+
+Each team member is displayed on a line, and any time off they requested, regardless of the status
+(:guilabel:`Validated` or :guilabel:`To Approve`), appears on the calendar.
+
+Each employee is color-coded. The employee's color is selected at random and does not correspond to
+the type of time off they requested.
+
+The status of the time of is represented by the color of the request either appearing solid
+(:guilabel:`Validated`) or striped (:guilabel:`To Approve`).
+
+The number of days or hours requested is written on the request (if there is enough space).
+
+At the bottom of the calendar, a bar graph shows how many people are projected to be out on any
+given day. The number on the bar represents the number of employees out for those highlighted days.
+
+Hover over a time off entry to view the details for the specific time off entry. The total number of
+hours or days are listed, along with the start and end time of the time off.
+
+.. image:: time_off/overview.png
+   :align: center
+   :alt: Overview of the user's team, with time off requests shown.
+
+.. _time_off/reporting:
+
+Allocate time off
+=================
+
+Once time off types and accrual plans have been configured, the next step is to allocate, or give,
+time off to employees. This section is only visible to users who have either :guilabel:`Time Off
+Officer` or :guilabel:`Administrator` access rights for the *Time Off* application.
+
+To create a new allocation, navigate to :menuselection:`Time Off app --> Approvals --> Allocations`.
+
+This presents a list of all current allocations, including their respective status.
+
+Click :guilabel:`Create` to allocate time off, and a blank allocation form appears.
+
+After entering a name for the allocation on the first blank field of the form, enter the following
+information:
+
+- :guilabel:`Time Off Type`: using the drop-down menu, select the type of time off that is being
+  allocated to the employees.
+- :guilabel:`Allocation Type`: select either :guilabel:`Regular Allocation` or :guilabel:`Accrual
+  Allocation`.
+- :guilabel:`Accrual Plan`: if :guilabel:`Accrual Allocation` is selected for the
+  :guilabel:`Allocation Type`, the :guilabel:`Accrual Plan` field appears. Using the drop-down menu,
+  select the accrual plan with which the allocation is associated. An accrual plan **must** be
+  selected for an :guilabel:`Accrual Allocation`.
+- :guilabel:`Validity Period/Start Date`: if :guilabel:`Regular Allocation` is selected for the
+  :guilabel:`Allocation Type`, this field is labeled :guilabel:`Validity Period`.
+
+  Using the calendar, select the beginning date for the allocation. If the allocation expires,
+  select the expiration date in the next date field. If the time off does *not* expire, leave the
+  second date field blank.
+
+  If :guilabel:`Accrual Allocation` is selected for the :guilabel:`Allocation Type`, this field is
+  labeled :guilabel:`Start Date`.
+
+  Using the calendar picker, select the start date for the allocation. If the allocation expires,
+  select the expiration date in the :guilabel:`Run until` field. If the time off does *not* expire,
+  leave the :guilabel:`Run until` field blank.
+- :guilabel:`Duration`: enter the amount of time that is being allocated to the employees. This
+  field displays the time in either :guilabel:`Hours` or :guilabel:`Days`, depending on how the
+  selected :ref:`Time Off Type <time_off/time-off-types>` is configured (in days or hours).
+- :guilabel:`Mode`: using the drop-down menu, select how the allocation is assigned. This selection
+  determines who receives the time off allocation. The options are :guilabel:`By Employee`,
+  :guilabel:`By Company`, :guilabel:`By Department`, or :guilabel:`By Employee Tag`.
+
+  Depending on what was selected for the :guilabel:`Mode`, this following field is labeled either:
+  :guilabel:`Employees`, :guilabel:`Company`, :guilabel:`Department`, or :guilabel:`Employee Tag`.
+
+  Using the drop-down menu, indicate the specific employees, company, department, or employee tags
+  who are receiving this time off.
+
+  Multiple selections can be made for either :guilabel:`Employees` or :guilabel:`Employee Tag`.
+
+  Only one selection can be made for the :guilabel:`Company` or :guilabel:`Department`.
+- :guilabel:`Add a reason...`: if any description or note is necessary to explain the time off
+  allocation, enter it in this field at the bottom of the form.
+
+.. _time_off/request-time-off:
+
+Request time off
+================
+
+Once an employee has been allocated time off, a request to use the time off can be submitted. Time
+off can be requested in one of two ways, either from the :ref:`dashboard <time_off/dashboard>` or
+from the :guilabel:`My Time Off` view.
+
+To access the dashboard, navigate to :menuselection:`Time Off app --> My Time Off --> Dashboard`.
+This is also the default view for the *Time Off* application.
+
+To access :guilabel:`My Time Off`, navigate to :menuselection:`Time Off app --> My Time Off --> My
+Time Off`. This presents a list view of all the time off requests for the employee.
+
+To create a new request for time off, click either the :guilabel:`New Time Off` button on the main
+*Time Off* dashboard, or the :guilabel:`Create` button in the :guilabel:`My Time Off` list view.
+Both buttons open a new time off request form.
+
+Enter the following information on the form:
+
+- :guilabel:`Time Off Type`: select the type of time off being requested from the drop-down menu.
+- :guilabel:`Dates`: enter the dates that the time off will fall under. There are two fields to
+  populate, the :guilabel:`From` and :guilabel:`To` fields. Click on either the :guilabel:`From` or
+  :guilabel:`To` field, and a calendar pop-up appears.
+
+  Click on the start date, then click on the end date. The selected start and end dates appear in
+  deep purple, and the dates between them appear in pale purple (if applicable).
+
+  If the time off requested is for a single day, click on the start date, then click the same date
+  again for the end date.
+
+  When the correct dates are selected/highlighted, click the :guilabel:`Apply` button.
+
+  The dates now populate the :guilabel:`From` and :guilabel:`To` fields.
+
+  - :guilabel:`Half Day`: if the time off request is for a half day, tick this box. When this is
+    selected, the :guilabel:`From` date field disappears, and is replaced with a drop-down menu.
+    Select either :guilabel:`Morning` or :guilabel:`Afternoon` to indicate which half of the day is
+    being requested.
+  - :guilabel:`Custom Hours`: if the time off requested is not a whole or half day, tick this box. A
+    :guilabel:`From` and :guilabel:`To` field appears beneath this option if selected. Using the
+    drop-down menu, select the start and end time for the time off request.
+
+- :guilabel:`Duration`: this field updates automatically once the :guilabel:`Date` section is
+  completed. If the :guilabel:`Date` section is modified, this section automatically updates to
+  reflect the total time off requested. This field is in either hours or days, depending on the
+  :guilabel:`Date` selections.
+- :guilabel:`Description`: enter a description for the time off request. This should include any
+  details that managers and approvers may need in order to approve the request.
+- :guilabel:`Supporting Document`: this field only appears if the :guilabel:`Time Off Type` selected
+  allows for the attachments of documents. Click the :guilabel:`Attach File` button, and a file
+  explorer window appears.
+
+  Navigate to the file(s) to attach, then click the :guilabel:`Open` button. The files then appear
+  on the time off request form. Multiple documents can be attached, if necessary.
+
+When the form is complete, click the :guilabel:`Save` button to save the information, and submit the
+request.
+
+.. image:: time_off/time-off-request.png
+   :align: center
+   :alt: A time off request form filled out for an employee home sick for two days with the flu.
+
+.. _time_off/request-allocation:
+
+Request allocation
+==================
+
+If an employee has used all their time off, or is going to run out of time off, they can request an
+allocation for additional time. Allocations can be requested in one of two ways, either from the
+:ref:`dashboard <time_off/dashboard>` or the :guilabel:`My Allocations` view.
+
+To access the dashboard, navigate to the :menuselection:`Time Off app --> My Time Off -->
+Dashboard`. This is also the default view for the *Time Off* application.
+
+To access :guilabel:`My Allocations`, navigate to the :menuselection:`Time Off app --> My Time Off
+--> My Allocations`. This presents a list view of all the allocations for the employee.
+
+To create a new allocation request, click either the :guilabel:`Allocation Request` button on the
+main *Time Off* dashboard, or the :guilabel:`Create` button in the :guilabel:`My Allocations` list
+view. Both buttons open a new allocation request form.
+
+After entering a name for the allocation in the first blank line on the form, enter the following
+information:
+
+- :guilabel:`Time Off Type`: select the type of time off being requested for the allocation from the
+  drop-down menu.
+- :guilabel:`Validity Period`: the current date populates the start date by default. If there is no
+  expiration on the time off type, there is no date populated as the end date. If the time off type
+  has an expiration date, the date automatically populates the end date field once the form is
+  saved.
+- :guilabel:`Duration`: enter the amount of time being requested. The format (either days or hours)
+  is in the same format as the time off type.
+- :guilabel:`Add a reason...`: enter a description for the allocation request. This should include
+  any details that managers and approvers may need in order to approve the request.
+
+When the form is complete, click the :guilabel:`Save` button to save the information, and submit the
+request.
+
+.. image:: time_off/allocation-request.png
+   :align: center
+   :alt: An allocation request form filled out for an employee requesting an additional week of
+         sick time.
+
+Approvals
+=========
+
+Most requests for time off and allocations need to go through the approval process, prior to the
+time off being allocated, and then granted to an employee. Requests either need one or two
+approvals, depending on how the specific type of time off is configured.
+
+Only users who can approve allocation and time off requests have the :guilabel:`Approvals` section
+visible in the *Time Off* application.
+
+Approve allocations
+-------------------
+
+To view allocations that need approval, navigate to :menuselection:`Time Off app --> Approvals -->
+Allocations`. The only allocations visible on this list are for employees the user has either
+:guilabel:`Time Off Officer` or :guilabel:`Administrator` access rights for in the *Time Off*
+application.
+
+The default filters that are configured to be in place when navigating to the
+:guilabel:`Allocations` list are :guilabel:`My Team` and :guilabel:`Active Employee`. This *only*
+presents employees on the user's team (who they manage) and active employees. Inactive users are not
+shown.
+
+The left side of the screen has various grouping options to narrow down the presented allocation
+requests.
+
+The options are :guilabel:`To Approve`, :guilabel:`To Submit`, :guilabel:`Refused`, and
+:guilabel:`Approved`.
+
+To view all allocation requests, click :guilabel:`All`.
+
+It is also possible to display allocation requests by department. Click on the department to only
+present allocations for that specific department.
+
+.. note::
+   The groupings on the left side only present allocation requests that fall under the default
+   filters of :guilabel:`My Team` and :guilabel:`Active Employee`. Only the statuses for allocation
+   requests that fall under those filters are presented on the left side.
+
+   For example, if there are no requests with a status of :guilabel:`To Submit`, that status option
+   does not appear in the left-hand side.
+
+   All departments for the user's employees appear in the list. If there are no allocation requests
+   that fall under that department matching the pre-configured filters, the list is blank.
+
+   It is always possible to remove any of the pre-configured filters, by clicking the :guilabel:`✖️
+   (remove)` icon on the specific filter to remove it.
+
+The status column displays the status of each request, with the status highlighted in a specific
+color.
+
+The :guilabel:`To Approve` requests are highlighted in yellow, :guilabel:`Approved` requests are
+highlighted in green, :guilabel:`To Submit` (drafts) requests are highlighted in blue, and the
+:guilabel:`Refused` requests are highlighted in gray.
+
+To approve an allocation request, click :guilabel:`✔ Validate` at the end of the line, to refuse a
+request, click :guilabel:`✖️ Refuse`.
+
+.. image:: time_off/allocations.png
+   :align: center
+   :alt: Allocations with the filter, groupings, and status sections highlighted.
+
+If more details are needed, click anywhere on the allocation request line (except for :guilabel:`✔
+Validate` and :guilabel:`✖️ Refuse`) to view the request in detail.
+
+Depending on the rights of the user, changes can be made on the allocation request form that
+appears. To modify the request, click the :guilabel:`Edit` button, make any desired changes, then
+click :guilabel:`Save`.
+
+It is also possible to approve or refuse the request from this form. Click the :guilabel:`Validate`
+button to approve, or the :guilabel:`Refuse` button to refuse the request.
+
+.. _time_off/approve-time-off:
+
+Approve time off
+----------------
+
+To view time off requests that need approval, navigate to :menuselection:`Time Off app --> Approvals
+--> Time Off`. The only time off requests visible on this list are for employees the user has either
+:guilabel:`Time Off Officer` or :guilabel:`Administrator` access rights for the *Time Off*
+application.
+
+The default filters in the :guilabel:`Time Off` list are :guilabel:`To Approve`, :guilabel:`My
+Team`, :guilabel:`Active Employee`, and :guilabel:`Active Time Off`. This only presents time off
+requests that need to be approved for current employees on the user's team, for requests that are
+active and *not* in a draft mode.
+
+The left side of the screen has various grouping options to narrow down the presented time off
+requests. Since only time off requests that need to be approved are shown, the only status options
+are :guilabel:`All` and :guilabel:`To Approve`.
+
+To view requests with other statuses, first remove the :guilabel:`To Approve` filter, by clicking
+the :guilabel:`✖️ (remove)` icon next to the :guilabel:`To Approve` filter to remove it.
+
+To display time off requests for specific departments, click on the department on the left-hand
+side. Only requests within the selected department are then presented.
+
+The status column displays the status of each request, with the status highlighted in a specific
+color.
+
+The :guilabel:`To Approve` requests are highlighted in yellow, and are the only ones that appear in
+the list by default. If the :guilabel:`To Approve` filter is removed, then all statuses appear.
+:guilabel:`Approved` requests are highlighted in green, :guilabel:`To Submit` (drafts) requests are
+highlighted in blue, and the :guilabel:`Refused` requests are highlighted in gray.
+
+To approve a time off request, click :guilabel:`👍 Approve` at the end of the line, to refuse a
+request, click :guilabel:`✖️ Refuse`.
+
+.. image:: time_off/time-off-requests.png
+   :align: center
+   :alt: Time off requests with the filter, groupings, and status sections highlighted.
+
+If more details are needed, click anywhere on the time off request line (except for :guilabel:`👍
+Approve` and :guilabel:`✖️ Refuse`) to load the time off request form. Depending on the rights of
+the user, changes can be made.
+
+To modify the request, click the :guilabel:`Edit` button, make any desired changes, then click
+:guilabel:`Save`.
+
+It is also possible to approve or refuse the request from this form. Click the :guilabel:`Approve`
+button to approve, or the :guilabel:`Refuse` button to refuse the request.
+
+My time off
+===========
+
+The :guilabel:`My Time Off` section of the *Time Off* application contains the time off dashboard,
+as well as the user's time off requests and allocations.
+
+.. _time_off/dashboard:
+
+Dashboard
+---------
+
+All users have access to the time off dashboard, which is the default view in the *Time Off*
+application. The dashboard can also be accessed at any point in the application by navigating to
+:menuselection:`Time Off app --> My Time Off --> Dashboard`.
+
+The current year is displayed, and the current day is highlighted in red.
+
+To change the view, click on the desired button at the top. The options are :guilabel:`Day`,
+:guilabel:`Week`, :guilabel:`Month`, or :guilabel:`Year` (the default).
+
+To change the presented dates, click the left and right arrows on either side of the
+:guilabel:`Today` button. The calendar view adjusts in increments of the presented view.
+
+For example, if :guilabel:`Week` is selected, the arrows adjust the view by one week.
+
+To change the view at any point to a view that includes the current date, click the
+:guilabel:`Today` button.
+
+Above the calendar view is a summary of the users time off balances. Every time off type that has
+been allocated appears in its own summary box. Each summary lists the type of time off, the
+corresponding icon, the current available balance (in hours or days), and an expiration date (if
+applicable).
+
+The legend on the right side of the calendar view displays the various time off types, with their
+corresponding colors. The status of the time off requests are shown as well.
+
+Time off that has been validated appears in a solid color (in the color specified in the Time Off
+Types part of the legend). Time off requests that still need to be approved appear with white
+stripes in the color. Refused time off requests have a colored line through the dates.
+
+New time off requests can be made from the dashboard. Click the :guilabel:`New Time Off` button at
+the top of the dashboard, and a new :ref:`time off form <time_off/request-time-off>` appears.
+
+New allocation requests can also be made from the dashboard. Click the :guilabel:`Allocation
+Request` button at the top of the dashboard to request more time off, and a new :ref:`allocation
+form <time_off/request-allocation>` appears.
+
+.. image:: time_off/dashboard.png
+   :align: center
+   :alt: Time off dashboard view with the legend, time off summaries, and view buttons highlighted.
+
+My time off
+-----------
+
+To view a list of all the user's time off requests, navigate to :menuselection:`Time Off app --> My
+Time Off --> My Time Off`. Here, all time off requests appear in a list view, both past and
+present.
+
+Other than the employee's name, the list includes the following information for each request: the
+:guilabel:`Time Off Type`, :guilabel:`Description`, :guilabel:`Start Date`, :guilabel:`End Date`,
+:guilabel:`Duration`, and the :guilabel:`Status`.
+
+A new time off request can be made from this view. Click the :guilabel:`Create` button to
+:ref:`request time off <time_off/request-time-off>`.
+
+My allocations
+--------------
+
+To view a list of all the users allocations, navigate to :menuselection:`Time Off app --> My Time
+Off --> My Allocations`. All allocations and requested allocations appear in a list view.
+
+The information presented includes: the :guilabel:`Time Off Type`, :guilabel:`Description`,
+:guilabel:`Duration`, :guilabel:`Allocation Type`, and the :guilabel:`Status`.
+
+A new allocation request can be made from this view, as well. Click the :guilabel:`Create` button to
+:ref:`request an allocation <time_off/request-allocation>`.
+
+Reporting
+=========
+
+The reporting feature allows users to view time off for their team, either by employee or type of
+time off. This allows users to see which employees are taking time off, how much time off they are
+taking, and what time off types are being used.
+
+By employee
+-----------
+
+To view a report of employee time off requests, navigate to :menuselection:`Time Off app -->
+Reporting --> by Employee`.
+
+The default report is a stacked bar chart with the filters of :guilabel:`Active Employee` and
+:guilabel:`Type` in place.
+
+Each employee is displayed in their own column, with the bar displaying how many days of each type
+of time off type they requested.
+
+The report can be displayed in other ways. Click the various options at the top of the report to
+view the data differently.
+
+The graph options are :guilabel:`Bar Chart`, :guilabel:`Line Chart`, or :guilabel:`Pie Chart`. The
+:guilabel:`Bar Chart` includes an option to present the data :guilabel:`Stacked`. Both the
+:guilabel:`Bar Chart` and :guilabel:`Line Chart` have options to present the data in either
+:guilabel:`Descending` or :guilabel:`Ascending` order.
+
+.. image:: time_off/bar-chart.png
+   :align: center
+   :alt: Report of time off, shown by each employee in a stacked bar chart.
+
+By type
+-------
+
+To view a list of approved time off, organized by time off type, navigate to :menuselection:`Time
+Off app --> Reporting --> by Type`. This shows each time off type in its own section.
+
+Click on a time off type to expand the list. Each request is listed, with the following information
+displayed: the :guilabel:`Employee`, :guilabel:`Number of Days`, :guilabel:`Request Type`,
+:guilabel:`Start Date`, :guilabel:`End Date`, :guilabel:`Status`, and the :guilabel:`Description`.
+
+The default filters in place for this report are :guilabel:`Approved Requests`, :guilabel:`Active
+Employee`, the :guilabel:`Current Year`, and the :guilabel:`Type`.
+
+.. image:: time_off/type-report.png
+   :align: center
+   :alt: Report of time off by type, with each request detailed in the list.

content/applications/inventory_and_mrp/manufacturing/management.rst

@@ -20,6 +20,6 @@ Manufacturing workflows
    management/configure_manufacturing_product
    management/split_merge
    management/work_order_dependencies
-   management/two_step_manufacturing
    management/one_step_manufacturing
+   management/two_step_manufacturing
    management/three_step_manufacturing

content/applications/inventory_and_mrp/manufacturing/management/one_step_manufacturing.rst

@@ -51,6 +51,8 @@ auto-populate with the components and operations specified on the |BOM|. If addi
 operations are required for the |MO| being configured, add them to the :guilabel:`Components` and
 :guilabel:`Work Orders` tabs by clicking :guilabel:`Add a line`.
 
+Finally, click :guilabel:`Confirm` to confirm the |MO|.
+
 Process manufacturing order
 ===========================
 
@@ -81,32 +83,75 @@ same process for each work order listed on the :guilabel:`Work Orders` tab.
 After completing all of the work orders, click :guilabel:`Produce All` at the top of the screen to
 mark the |MO| as :guilabel:`Done`, and register the manufactured product(s) into inventory.
 
-Tablet view workflow
---------------------
+Shop Floor workflow
+-------------------
 
-To complete the work orders for an |MO| using the tablet view, begin by navigating to
-:menuselection:`Manufacturing --> Operations --> Manufacturing Orders`, and then select a
-manufacturing order.
+To complete the work orders for an |MO| using the *Shop Floor* module, begin by navigating to
+:menuselection:`Manufacturing --> Operations --> Manufacturing Orders`, and then select an |MO|.
 
-Next, click on the :guilabel:`Work Orders` tab, and then select the :guilabel:`📱 (tablet)` button
-on the line of the first work order to be processed. This opens the tablet view.
+On the |MO|, click on the :guilabel:`Work Orders` tab, and then select the :guilabel:`↗️ (square
+with arrow coming out of it)` button on the line of the first work order to be processed. Doing so
+opens a :guilabel:`Work Orders` pop-up window, with details and processing options for the work
+order.
 
-.. image:: one_step_manufacturing/tablet-view-button.png
+On the pop-up window, select the :guilabel:`Open Shop Floor` button at the top-left of the window to
+open the *Shop Floor* module.
+
+.. image:: one_step_manufacturing/shop-floor-button.png
    :align: center
-   :alt: The tablet view button for a work order on a manufacturing order.
+   :alt: The Open Shop Floor button for a work order on a manufacturing order.
 
-After opening the tablet view, Odoo *Manufacturing* automatically starts a timer that keeps track of
-how long the work order takes to complete. After completing the work order, click the
-:guilabel:`Mark as Done` button in the top-right corner of the tablet view.
+When accessed directly from a specific work order within an |MO|, *Shop Floor* defaults to the page
+for the work center where the work order is configured to be carried out. The page shows a card for
+the work order that displays the |MO| number, the product and number of units to be produced, and
+the steps required to complete the work order.
 
-Clicking :guilabel:`Mark as Done` while there is at least one more work order left to complete opens
-a page that lists the next work order. Click on that work order to open it in the tablet view.
+.. image:: one_step_manufacturing/work-order-card.png
+   :align: center
+   :alt: A work order card on a work center page in the Shop Floor module.
 
-Once the final work order for the |MO| has been reached, a :guilabel:`Mark as Done and Close MO`
-button appears on the tablet view in addition to the :guilabel:`Mark as Done` button. Click
-:guilabel:`Mark as Done and Close MO` to mark the |MO| as :guilabel:`Done` and register the
-manufactured product(s) into inventory.
+A work order is processed by completing each step listed on its card. This can be done by clicking
+on a step and following the instructions listed on the pop-up window that appears. Once the step is
+completed, click :guilabel:`Next` to move on to the next step, if any are required.
 
-It is also possible to complete the final operation while keeping the |MO| open, by clicking
-:guilabel:`Mark as Done`. In this case, the |MO| can be closed later by clicking the
-:guilabel:`Produce All` button on the order.
+Alternatively, work order steps can be completed by clicking the checkbox that appears on the right
+side of the step's line on the work order card. When using this method, the step is automatically
+marked as completed, without a pop-up window appearing.
+
+The final step on a work order card is titled *Register Production*. This step is used to register
+the number of product units that were produced. If the number produced is equal to the number that
+the |MO| was created for, click the :guilabel:`# Units` button on the right side of the line to
+automatically register that number as the quantity produced.
+
+If a different number must be entered, click the :guilabel:`Register Production` step to open a
+pop-up window. Enter the number of units produced in the :guilabel:`Units` field, and then click
+:guilabel:`Validate` to register that number.
+
+.. note::
+   The *Register Production* step appears on every work order card. It must be completed for the
+   first work order that is processed. After doing so, the step appears as already completed for
+   each remaining work order in the |MO|.
+
+After completing all of the steps for a work order, a button appears on the footer of the work order
+card. If any other work orders must be completed before the |MO| can be closed, the button is titled
+:guilabel:`Mark as Done`. If there are no additional work orders to complete, the button is titled
+:guilabel:`Close Production`.
+
+Clicking :guilabel:`Mark as Done` causes the work order card to fade away. Once it disappears
+completely, the work order's status is marked as *Finished* on the |MO|, and the next work order
+appears in the *Shop Floor* module, on the page of the work center where it is configured to be
+carried out. Any additional work orders can be processed using the instructions detailed in this
+section.
+
+Clicking :guilabel:`Close Production` causes the work order card to fade away. Once it disappears,
+the |MO| is marked as *Done*, and the units of the product that were produced are entered into
+inventory.
+
+After clicking :guilabel:`Mark as Done` or :guilabel:`Close Production`, each button is replaced by
+an :guilabel:`Undo` button. Click the :guilabel:`Undo` button before the work order card fades away
+to keep the work order open.
+
+.. tip::
+   This section details the basic workflow for processing an |MO| in the *Shop Floor* module. For a
+   more in-depth explanation of the module and all of its features, please see the :ref:`Shop Floor
+   overview <manufacturing/shop_floor/shop_floor_overview>` documentation.

content/applications/inventory_and_mrp/manufacturing/management/three_step_manufacturing.rst

@@ -106,35 +106,78 @@ same process for each work order listed on the :guilabel:`Work Orders` tab.
 After completing all of the work orders, click :guilabel:`Produce All` at the top of the screen to
 mark the |MO| as :guilabel:`Done`, and register the manufactured product(s) into inventory.
 
-Tablet view workflow
---------------------
+Shop Floor workflow
+-------------------
 
-To complete the work orders for an |MO| using the tablet view, begin by navigating to
-:menuselection:`Manufacturing --> Operations --> Manufacturing Orders`, and then select a
-manufacturing order.
+To complete the work orders for an |MO| using the *Shop Floor* module, begin by navigating to
+:menuselection:`Manufacturing --> Operations --> Manufacturing Orders`, and then select an |MO|.
 
-Next, click on the :guilabel:`Work Orders` tab, and then select the :guilabel:`📱 (tablet)` button
-on the line of the first work order to be processed. This opens the tablet view.
+On the |MO|, click on the :guilabel:`Work Orders` tab, and then select the :guilabel:`↗️ (square
+with arrow coming out of it)` button on the line of the first work order to be processed. Doing so
+opens a :guilabel:`Work Orders` pop-up window, with details and processing options for the work
+order.
 
-.. image:: three_step_manufacturing/tablet-view-button.png
+On the pop-up window, select the :guilabel:`Open Shop Floor` button at the top-left of the window to
+open the *Shop Floor* module.
+
+.. image:: three_step_manufacturing/shop-floor-button.png
    :align: center
-   :alt: The tablet view button for a work order on a manufacturing order.
+   :alt: The Open Shop Floor button for a work order on a manufacturing order.
 
-After opening the tablet view, Odoo *Manufacturing* automatically starts a timer that keeps track of
-how long the work order takes to complete. After completing the work order, click the
-:guilabel:`Mark as Done` button in the top-right corner of the tablet view.
+When accessed directly from a specific work order within an |MO|, *Shop Floor* defaults to the page
+for the work center where the work order is configured to be carried out. The page shows a card for
+the work order that displays the |MO| number, the product and number of units to be produced, and
+the steps required to complete the work order.
 
-Clicking :guilabel:`Mark as Done` while there is at least one more work order left to complete opens
-a page that lists the next work order. Click on that work order to open it in the tablet view.
+.. image:: three_step_manufacturing/work-order-card.png
+   :align: center
+   :alt: A work order card on a work center page in the Shop Floor module.
 
-Once the final work order for the |MO| has been reached, a :guilabel:`Mark as Done and Close MO`
-button appears on the tablet view in addition to the :guilabel:`Mark as Done` button. Click
-:guilabel:`Mark as Done and Close MO` to mark the |MO| as :guilabel:`Done`, and register the
-manufactured product(s) into inventory.
+A work order is processed by completing each step listed on its card. This can be done by clicking
+on a step, and following the instructions listed on the pop-up window that appears. Once the step is
+completed, click :guilabel:`Next` to move on to the next step, if any are required.
 
-It is also possible to complete the final work order while keeping the |MO| open, by clicking
-:guilabel:`Mark as Done`. In this case, the |MO| can be closed at a later time by clicking the
-:guilabel:`Produce All` button on the |MO|.
+Alternatively, work order steps can be completed by clicking the checkbox that appears on the right
+side of the step's line on the work order card. When using this method, the step is automatically
+marked as completed, without a pop-up window appearing.
+
+The final step on a work order card is titled *Register Production*. This step is used to register
+the number of product units that were produced. If the number produced is equal to the number that
+the |MO| was created for, click the :guilabel:`# Units` button on the right side of the line to
+automatically register that number as the quantity produced.
+
+If a different number must be entered, click the :guilabel:`Register Production` step to open a
+pop-up window. Enter the number of units produced in the :guilabel:`Units` field, and then click
+:guilabel:`Validate` to register that number.
+
+.. note::
+   The *Register Production* step appears on every work order card. It must be completed for the
+   first work order that is processed. After doing so, the step appears as already completed for
+   each remaining work order in the |MO|.
+
+After completing all of the steps for a work order, a button appears on the footer of the work order
+card. If any other work orders must be completed before the |MO| can be closed, the button is titled
+:guilabel:`Mark as Done`. If there are no additional work orders to complete, the button is titled
+:guilabel:`Close Production`.
+
+Clicking :guilabel:`Mark as Done` causes the work order card to fade away. Once it disappears
+completely, the work order's status is marked as *Finished* on the |MO|, and the next work order
+appears in the *Shop Floor* module, on the page of the work center where it is configured to be
+carried out. Any additional work orders can be processed using the instructions detailed in this
+section.
+
+Clicking :guilabel:`Close Production` causes the work order card to fade away. Once it disappears,
+the |MO| is marked as *Done*, and the units of the product that were produced are entered into
+inventory.
+
+After clicking :guilabel:`Mark as Done` or :guilabel:`Close Production`, each button is replaced by
+an :guilabel:`Undo` button. Click the :guilabel:`Undo` button before the work order card fades away
+to keep the work order open.
+
+.. tip::
+   This section details the basic workflow for processing an |MO| in the *Shop Floor* module. For a
+   more in-depth explanation of the module and all of its features, please see the :ref:`Shop Floor
+   overview <manufacturing/shop_floor/shop_floor_overview>` documentation.
 
 Process finished product transfer
 =================================

content/applications/inventory_and_mrp/manufacturing/management/two_step_manufacturing.rst

@@ -103,31 +103,75 @@ same process for each work order listed on the :guilabel:`Work Orders` tab.
 After completing all of the work orders, click :guilabel:`Produce All` at the top of the screen to
 mark the |MO| as :guilabel:`Done`, and register the manufactured product(s) into inventory.
 
-Tablet view workflow
---------------------
+Shop Floor workflow
+-------------------
 
-To complete the work orders for an |MO| using the tablet view, begin by navigating to
+To complete the work orders for an |MO| using the *Shop Floor* module, begin by navigating to
 :menuselection:`Manufacturing --> Operations --> Manufacturing Orders`, and then select an |MO|.
 
-Next, click on the :guilabel:`Work Orders` tab, then select the :guilabel:`📱 (tablet)` button on
-the line of the first work order to be processed. This opens the tablet view.
+On the |MO|, click on the :guilabel:`Work Orders` tab, and then select the :guilabel:`↗️ (square
+with arrow coming out of it)` button on the line of the first work order to be processed. Doing so
+opens a :guilabel:`Work Orders` pop-up window, with details and processing options for the work
+order.
 
-.. image:: two_step_manufacturing/tablet-view-button.png
+On the pop-up window, select the :guilabel:`Open Shop Floor` button at the top-left of the window to
+open the *Shop Floor* module.
+
+.. image:: two_step_manufacturing/shop-floor-button.png
    :align: center
-   :alt: The tablet view button for a work order on a manufacturing order.
+   :alt: The Open Shop Floor button for a work order on a manufacturing order.
 
-After opening the tablet view, Odoo *Manufacturing* automatically starts a timer that keeps track of
-how long the work order takes to complete. After completing the work order, click the
-:guilabel:`Mark as Done` button in the top-right corner of the tablet view.
+When accessed directly from a specific work order within an |MO|, *Shop Floor* defaults to the page
+for the work center where the work order is configured to be carried out. The page shows a card for
+the work order that displays the |MO| number, the product and number of units to be produced, and
+the steps required to complete the work order.
 
-Clicking :guilabel:`Mark as Done` while there is at least one more work order left to complete opens
-a page that lists the next work order. Click on that work order to open it in the tablet view.
+.. image:: two_step_manufacturing/work-order-card.png
+   :align: center
+   :alt: A work order card on a work center page in the Shop Floor module.
 
-Once the final work order for the |MO| has been reached, a :guilabel:`Mark as Done and Close MO`
-button appears on the tablet view in addition to the :guilabel:`Mark as Done` button. Click
-:guilabel:`Mark as Done and Close MO` to mark the |MO| as :guilabel:`Done`, and register the
-manufactured product(s) into inventory.
+A work order is processed by completing each step listed on its card. This can be done by clicking
+on a step and following the instructions listed on the pop-up window that appears. Once the step is
+completed, click :guilabel:`Next` to move on to the next step, if any are required.
 
-It is also possible to complete the final operation while keeping the |MO| open, by clicking
-:guilabel:`Mark as Done`. In this case, the |MO| can be closed at a later time by clicking the
-:guilabel:`Produce All` button on the order.
+Alternatively, work order steps can be completed by clicking the checkbox that appears on the right
+side of the step's line on the work order card. When using this method, the step is automatically
+marked as completed, without a pop-up window appearing.
+
+The final step on a work order card is titled *Register Production*. This step is used to register
+the number of product units that were produced. If the number produced is equal to the number that
+the |MO| was created for, click the :guilabel:`# Units` button on the right side of the line to
+automatically register that number as the quantity produced.
+
+If a different number must be entered, click the :guilabel:`Register Production` step to open a
+pop-up window. Enter the number of units produced in the :guilabel:`Units` field, and then click
+:guilabel:`Validate` to register that number.
+
+.. note::
+   The *Register Production* step appears on every work order card. It must be completed for the
+   first work order that is processed. After doing so, the step appears as already completed for
+   each remaining work order in the |MO|.
+
+After completing all of the steps for a work order, a button appears on the footer of the work order
+card. If any other work orders must be completed before the |MO| can be closed, the button is titled
+:guilabel:`Mark as Done`. If there are no additional work orders to complete, the button is titled
+:guilabel:`Close Production`.
+
+Clicking :guilabel:`Mark as Done` causes the work order card to fade away. Once it disappears
+completely, the work order's status is marked as *Finished* on the |MO|, and the next work order
+appears in the *Shop Floor* module, on the page of the work center where it is configured to be
+carried out. Any additional work orders can be processed using the instructions detailed in this
+section.
+
+Clicking :guilabel:`Close Production` causes the work order card to fade away. Once it disappears,
+the |MO| is marked as *Done*, and the units of the product that were produced are entered into
+inventory.
+
+After clicking :guilabel:`Mark as Done` or :guilabel:`Close Production`, each button is replaced by
+an :guilabel:`Undo` button. Click the :guilabel:`Undo` button before the work order card fades away
+to keep the work order open.
+
+.. tip::
+   This section details the basic workflow for processing an |MO| in the *Shop Floor* module. For a
+   more in-depth explanation of the module and all of its features, please see the :ref:`Shop Floor
+   overview <manufacturing/shop_floor/shop_floor_overview>` documentation.

content/applications/inventory_and_mrp/quality/quality_check_types/instructions_check.rst

@@ -2,6 +2,7 @@
 Instructions quality check
 ==========================
 
+.. |MO| replace:: :abbr:`MO (Manufacturing Order)`
 .. |QCP| replace:: :abbr:`QCP (Quality Control Point)`
 
 In Odoo *Quality*, an *Instructions* check is one of the quality check types that can be selected
@@ -9,8 +10,8 @@ when creating a new quality check or quality control point (QCP). *Instructions*
 text entry field that allows the creator to provide instructions for how to complete the check.
 
 For a full overview of how to configure a quality check or a |QCP|, see the documentation on
-:ref:`quality checks <quality/quality_management/quality-checks>` and :ref:`quality control
-points <quality/quality_management/quality-control-points>`.
+:ref:`quality checks <quality/quality_management/quality-checks>` and :ref:`quality control points
+<quality/quality_management/quality-control-points>`.
 
 Process an Instructions quality check
 =====================================
@@ -65,26 +66,33 @@ Process work order quality check
 When configuring a |QCP| that is triggered by a manufacturing order, a specific work order can also
 be specified in the :guilabel:`Work Order Operation` field on the |QCP| form. If a work order is
 specified, an *Instructions* quality check is created for that specific work order, rather than the
-manufacturing order as a whole.
+|MO| as a whole.
 
-Quality checks configured for work orders must be completed from the tablet view. To do so, begin by
-navigating to :menuselection:`Manufacturing --> Operations --> Manufacturing Orders`. Select a
-manufacturing order that includes a work order for which a quality check is required. Open the
-tablet view for that work order by clicking the :guilabel:`📱 (tablet)` button on the order's line.
+Quality checks configured for work orders **must** be completed from the *Shop Floor* module. To do
+so, begin by navigating to :menuselection:`Manufacturing --> Operations --> Manufacturing Orders`.
+Select an |MO| that includes a work order for which an *Instructions* quality check is required.
 
-With tablet view open, complete the steps listed on the left side of the screen until the
-*Instructions* quality check step is reached. Upon reaching the check, the instructions for how to
-complete it will appear at the top of the screen. Follow the instructions, then click
-:guilabel:`Next` to move on to the next step.
+On the |MO|, select the :guilabel:`Work Orders` tab, and click the :guilabel:`Open Work Order
+(square with arrow coming out of it)` button on the line of the work order to be processed. On the
+resulting :guilabel:`Work Orders` pop-up window, click the :guilabel:`Open Shop Floor` button to
+open the *Shop Floor* module.
 
-.. image:: instructions_check/work-order-instructions-check.png
+When accessed from a specific work order, the *Shop Floor* module opens to the page for the work
+center where the order is configured to be processed, and isolates the work order's card so that no
+other cards are shown.
+
+Begin processing the work order's steps until the *Instructions* quality check step is reached.
+Click on the step to open a pop-up window that details how to complete the quality check. Once
+completed, click the :guilabel:`Next` button to complete the check, and move on to the next step.
+
+.. image:: instructions_check/instructions-check-shop-floor.png
    :align: center
-   :alt: An Instructions check for a work order.
+   :alt: An Instruction check as it appears in the Shop Floor module.
 
-If an issue or defect is found during the quality check, a quality alert may need to be created to
-notify a quality team. To do so, click the :guilabel:`☰ (menu)` button in the tablet view, and then
-select :guilabel:`Quality Alert` from the :guilabel:`Menu` pop-up window.
+Alternatively, an *Instructions* quality check can be completed by clicking the checkbox that
+appears on the right side of the step's line on the work order card. When using this method, the
+quality check automatically passes, without a pop-up window appearing.
 
-Clicking :guilabel:`Quality Alert` opens a :guilabel:`Quality Alerts` pop-up window, from which a
-quality alert can be created. For a complete guide to quality alert creation, view the documentation
-on :ref:`quality alerts <quality/quality_management/quality-alerts>`.
+.. note::
+   For a full guide to the *Shop Floor* module, see the :ref:`Shop Floor overview
+   <manufacturing/shop_floor/shop_floor_overview>` documentation.

content/applications/inventory_and_mrp/quality/quality_check_types/picture_check.rst

@@ -2,6 +2,7 @@
 Take a Picture quality check
 ============================
 
+.. |MO| replace:: :abbr:`MO (Manufacturing Order)`
 .. |QCP| replace:: :abbr:`QCP (Quality Control Point)`
 .. |QCPs| replace:: :abbr:`QCP (Quality Control Points)`
 
@@ -20,7 +21,7 @@ This documentation only details the configuration options that are unique to *Ta
 quality checks and |QCPs|. For a full overview of all the configuration options available when
 creating a single check or a |QCP|, see the documentation on :ref:`quality checks
 <quality/quality_management/quality-checks>` and :ref:`quality control points
-<quality/quality_management/quality-checks>`.
+<quality/quality_management/quality-control-points>`.
 
 Quality check
 -------------
@@ -39,10 +40,10 @@ follows:
    :align: center
    :alt: A quality check form configured for a Take a Picture quality check.
 
-Quality Control Point (QCP)
----------------------------
+Quality control point
+---------------------
 
-To create a |QCP| that will generate *Take a Picture* quality checks automatically, navigate to
+To create a |QCP| that generates *Take a Picture* quality checks automatically, navigate to
 :menuselection:`Quality --> Quality Control --> Control Points`, and click :guilabel:`New`. Fill out
 the new |QCP| form as follows:
 
@@ -124,33 +125,52 @@ specified in the :guilabel:`Work Order Operation` field on the |QCP| form. If a
 specified, a *Take a Picture* quality check is created for that specific work order, rather than the
 manufacturing order as a whole.
 
-*Take a Picture* quality checks created for work orders must be completed from the tablet view. To
-do so, begin by navigating to :menuselection:`Manufacturing --> Operations --> Manufacturing
-Orders`. Select a manufacturing order that includes a work order for which a quality check is
-required. Open the tablet view for that work order by selecting the :guilabel:`Work Orders` tab, and
-then clicking the :guilabel:`📱 (tablet)` button on the order's line.
+*Take a Picture* quality checks configured for work orders **must** be completed from the *Shop
+Floor* module. To do so, begin by navigating to :menuselection:`Manufacturing --> Operations -->
+Manufacturing Orders`. Then, select an |MO| that includes a work order for which a *Take a Picture*
+quality check is required.
 
-With tablet view open, complete the steps listed on the left side of the screen until the *Take a
-Picture* quality check step is reached. Upon reaching the check, follow the instructions for how to
-take the picture, which appear at the top of the screen.
+On the |MO|, select the :guilabel:`Work Orders` tab, and then click the :guilabel:`Open Work Order
+(external link icon)` button on the line of the work order to be processed. On the resulting
+:guilabel:`Work Orders` pop-up window, click the :guilabel:`Open Shop Floor` button to open the
+*Shop Floor* module.
 
-After taking the picture, make sure it is stored on the device being used to process the work order
-(computer, tablet, etc.). Then, click the :guilabel:`Take a Picture` button to open the device's
-file manager. In the file manager, navigate to the picture, select it, and click :guilabel:`Open` to
-attach it. Finally, click :guilabel:`Validate` to complete the quality check.
+When accessed from a specific work order, the *Shop Floor* module opens to the page for the work
+center where the order is configured to be processed, and isolates the work order's card, so no
+other cards are shown.
 
-.. image:: picture_check/work-order-picture-check.png
+Process the work order's steps until the *Take a Picture* quality check step is reached. Click on
+the step to open a pop-up window that includes instructions for how the picture should be taken.
+After taking the picture, make sure it is stored on the device being used to process the quality
+check (computer, tablet, etc.).
+
+Then, click the :guilabel:`Take a Picture` button on the pop-up window to open the device's file
+manager. In the file manager, navigate to the picture, select it, and click :guilabel:`Open` to
+attach it.
+
+Finally, click :guilabel:`Validate` at the bottom of the pop-up window to complete the quality
+check. The pop-up window then moves on to the next step of the work order.
+
+.. image:: picture_check/picture-check-shop-floor.png
    :align: center
-   :alt: A Take a Picture check for a manufacturing work order.
+   :alt: A Take a Picture check in the Shop Floor module.
 
-If a quality alert must be created, do so by clicking the :guilabel:`☰ (three horizontal lines)`
-button in the tablet view, and selecting :guilabel:`Quality Alert` from the :guilabel:`Menu` pop-up
-window. A :guilabel:`Quality Alerts` pop-up window appears, from which a quality alert can be
-created. For a complete guide on how to fill out quality alert forms, view the documentation on
-:ref:`quality alerts <quality/quality_management/quality-alerts>`.
+If a quality alert must be created, exit the pop-up window by clicking the :guilabel:`X (close)`
+button in the top-right corner.
 
-Review a picture attached to a check
-====================================
+Then, click the :guilabel:`⋮ (three vertical dots)` button on the bottom-right corner of the work
+order card to open the :guilabel:`What do you want to do?` pop-up window.
+
+On the :guilabel:`What do you want to do?` pop-up window, select the :guilabel:`Create a Quality
+Alert` button. Doing so opens a blank quality alert form in a new :guilabel:`Quality Alerts` pop-up
+window.
+
+.. seealso::
+   For a complete guide on how to fill out quality alert forms, view the documentation on
+   :doc:`quality alerts <../quality_management/quality_alerts>`.
+
+Review picture attached to quality check
+========================================
 
 After a picture has been attached to a check, it can then be reviewed by quality team members or
 other users. To do so, navigate to :menuselection:`Quality --> Quality Control --> Quality Checks`,

content/developer/howtos/upgrade_custom_db.rst

@@ -33,7 +33,6 @@ These are the steps to follow to upgrade customized databases:
 #. :ref:`Test extensively and do a rehearsal <upgrade_custom/testing_rehearsal>`.
 #. :ref:`Upgrade the production database <upgrade_custom/production>`.
 
-
 .. _upgrade_custom/stop_developments:
 
 Step 1: Stop the developments
@@ -47,14 +46,13 @@ Needless to say, bug fixing is exempt from this recommendation.
 Once you have stopped development, it is a good practice to assess the developments made and compare
 them with the features introduced between your current version and the version you are targeting.
 Challenge the developments as much as possible and find functional workarounds. Removing redundancy
-between your developments and the standard version of Odoo will lead to an eased
-upgrade process and reduce technical debt.
+between your developments and the standard version of Odoo will lead to an eased upgrade process
+and reduce technical debt.
 
 .. note::
    You can find information on the changes between versions in the `Release Notes
    <https:/odoo.com/page/release-notes>`_.
 
-
 .. _upgrade_custom/request_upgrade:
 
 Step 2: Request an upgraded database
@@ -71,7 +69,6 @@ properly. If that's not the case, and the upgrade request fails, request the ass
 the `support page <https://odoo.com/help?stage=migration>`_ by selecting the option related to
 testing the upgrade.
 
-
 .. _upgrade_custom/empty_database:
 
 Step 3: Empty database
@@ -85,7 +82,7 @@ features, and guarantees that they will not cause any issues when upgrading the
 Making the custom modules work in an empty database also helps avoid changes and wrong
 configurations that might be present in the production database (like studio customization,
 customized website pages, email templates or translations). They are not intrinsically related to
-the custom modules and that can raise unwanted issues in this stage of the upgraded process.
+the custom modules and that can raise unwanted issues in this stage of the upgrade process.
 
 To make custom modules work on an empty database we advise to follow these steps:
 
@@ -190,24 +187,84 @@ To make sure the custom code is working flawlessly in the new version, follow th
 Migrate the data
 ----------------
 
-During the upgrade of the custom modules, you might have to use migration scripts to reflect changes
-from the source code to their corresponding data.
+During the upgrade of the custom modules, you might have to use
+:doc:`upgrade scripts <../reference/upgrade_scripts>` to reflect changes from the source code
+to their corresponding data. Together with the upgrade scripts, you can also make use of the
+:doc:`../reference/upgrade_utils` and its helper functions.
 
 - Any technical data that was renamed during the upgrade of the custom code (models, fields,
-  external identifiers) should be renamed using migration scripts to avoid data loss during the
-  module upgrade.
+  external identifiers) should be renamed using upgrade scripts to avoid data loss during the
+  module upgrade. See also: :meth:`rename_field`, :meth:`rename_model`, :meth:`rename_xmlid`.
 - Data from standard models removed from the source code of the newer Odoo version and from the
   database during the standard upgrade process might need to be recovered from the old model table
   if it is still present.
 
-Migration scripts can also be used to:
+   .. example::
+      Custom fields for model ``sale.subscription`` are not automatically migrated from Odoo 15 to
+      Odoo 16 (when the model was merged into ``sale.order``). In this case, a SQL query can be
+      executed on an upgrade script to move the data from one table to the other. Take into account
+      that all columns/fields must already exist, so consider doing this in a ``post-`` script (See
+      :ref:`upgrade-scripts/phases`).
+
+      .. spoiler::
+
+         .. code-block:: python
+
+            def migrate(cr, version):
+               cr.execute(
+                  """
+                  UPDATE sale_order so
+                     SET custom_field = ss.custom_field
+                    FROM sale_subscription ss
+                   WHERE ss.new_sale_order_id = so.id
+                  """
+               )
+
+         Check the documentation for more information on :doc:`../reference/upgrade_scripts`.
+
+Upgrade scripts can also be used to:
 
 - Ease the processing time of an upgrade. For example, to store the value of computed stored fields
   on models with an excessive number of records by using SQL queries.
-- Recompute fields in case the computation of their value has changed.
-- Uninstall unwanted custom modules.
+- Recompute fields in case the computation of their value has changed. See also
+  :meth:`recompute_fields`.
+- Uninstall unwanted custom modules. See also :meth:`remove_module`.
 - Correct faulty data or wrong configurations.
 
+Running and testing upgrade scripts
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+.. tabs::
+
+   .. group-tab:: Odoo Online
+
+      As the instalation of custom modules containing Python files is not allowed on Odoo Online
+      databases, it is not possible to run upgrade scripts on this platform.
+
+   .. group-tab:: Odoo.sh
+
+      As explained on the `Odoo.sh` tab of :ref:`upgrade/request-test-database`, Odoo.sh is
+      integrated with the upgrade platform.
+
+      Once the upgrade of a staging branch is on "Update on commit" mode, each time a commit is
+      pushed on the branch, the upgraded backup is restored and all the custom modules are updated.
+      This update includes the execution of the upgrade scripts.
+
+      When upgrading the production database, the execution of the upgrade scripts is also part of
+      the update of the custom modules done by the platform when the upgraded database is restored.
+
+   .. group-tab:: On-premise
+
+      Once you receive the upgraded dump of the database from the `Upgrade platform
+      <https://upgrade.odoo.com>`_, deploy the database and update all the custom modules by
+      invoking the command :doc:`odoo-bin </developer/reference/cli>` in the shell.
+      To update the custom modules, use the option: `-u <modules>,
+      --update <modules>`.
+
+      .. important::
+         As mentioned in the :doc:`CLI documentation </developer/reference/cli>`, the command used
+         to call the CLI depends on how you installed Odoo.
+
 .. _upgrade_custom/upgraded_database/test_custom:
 
 Test the custom modules
@@ -221,13 +278,12 @@ Things to pay attention to:
 
 - Views not working: During the upgrade, if a view causes issues because of its content, it gets
   disabled. You can find the information on disabled views on the :ref:`Upgrade report
-  <upgrade/upgrade_report>`. This view needs to be activated again. To achieve this, we recommend
-  the use of migration scripts.
+  <upgrade/upgrade_report>`. This view needs to be activated again (or removed if not useful anymore).
+  To achieve this, we recommend the use of upgrade scripts.
 - :doc:`Module data <../tutorials/define_module_data>` not updated: Custom records that have the
   ``noupdate`` flag are not updated when upgrading the module in the new database. For the custom
-  data that needs to be updated due to changes in the new version, we recommend to use migration
-  scripts to do so.
-
+  data that needs to be updated due to changes in the new version, we recommend to use upgrade
+  scripts to do so. See also: :meth:`update_record_from_xml`.
 
 .. _upgrade_custom/testing_rehearsal:
 
@@ -247,7 +303,6 @@ In addition to that, make a full rehearsal of the upgrade process the day before
 production database to avoid undesired behavior during the upgrade and to detect any issue that
 might have occurred with the migrated data.
 
-
 .. _upgrade_custom/production:
 
 Step 6: Production upgrade

content/developer/reference.rst

@@ -12,5 +12,7 @@ Reference
     reference/user_interface
     reference/standard_modules
     reference/cli
+    reference/upgrade_scripts
+    reference/upgrade_utils
     reference/external_api
     reference/extract_api

content/developer/reference/backend/testing.rst

@@ -58,19 +58,6 @@ related to testing Odoo content (modules, mainly):
 
 .. autofunction:: odoo.tests.tagged
 
-By default, tests are run once right after the corresponding module has been
-installed. Test cases can also be configured to run after all modules have
-been installed, and not run right after the module installation::
-
-  # coding: utf-8
-  from odoo.tests import HttpCase, tagged
-
-  # This test should only be executed after all modules have been installed.
-  @tagged('-at_install', 'post_install')
-  class WebsiteVisitorTests(HttpCase):
-    def test_create_visitor_on_tracked_page(self):
-        Page = self.env['website.page']
-
 The most common situation is to use
 :class:`~odoo.tests.TransactionCase` and test a property of a model
 in each method::
@@ -190,7 +177,7 @@ they're not going to get run:
     import unittest
     from odoo.tests import tagged
 
-    @tagged('standard', 'at_install')
+    @tagged('standard', 'post_install')
     class SmallTest(unittest.TestCase):
         ...
 
@@ -234,15 +221,19 @@ Special tags
   :option:`--test-tags <odoo-bin --test-tags>` also defaults to ``standard``.
 
   That means untagged test will be executed by default when tests are enabled.
-- ``at_install``: Means that the test will be executed right after the module
-  installation and before other modules are installed. This is a default
-  implicit tag.
-- ``post_install``: Means that the test will be executed after all the modules
-  are installed. This is what you want for HttpCase tests most of the time.
 
-  Note that this is *not exclusive* with ``at_install``, however since you
-  will generally not want both ``post_install`` is usually paired with
-  ``-at_install`` when tagging a test class.
+- ``post_install``: Means that the test will be executed after all the modules
+  are installed. This is a default implicit tag.
+
+- ``at_install``: Means that the test will be executed right after the module
+  installation and before other modules are installed.
+
+  This should be used seldomly as it prevents test runs from being parallelized
+  on runbot. A valuable addition is a comment above to test to explain why it
+  needs to be run before other modules are installed.
+
+  Note that this is *exclusive* with ``post_install`` so ``at_install`` is
+  usually paired with ``-post_install`` when tagging a test class.
 
 Examples
 ~~~~~~~~

content/developer/reference/upgrade_scripts.rst

@@ -0,0 +1,101 @@
+===============
+Upgrade scripts
+===============
+
+An upgrade script is a Python file containing a function called :meth:`migrate`, which the upgrade
+process invokes during the update of a module.
+
+.. method:: migrate(cr, version)
+
+   :param cr: current database cursor
+   :type cr: :class:`~odoo.sql_db.Cursor`
+   :param str version: installed version of the module
+
+Typically, this function executes one or multiple SQL queries and can also access Odoo's ORM, as
+well as the :doc:`./upgrade_utils`.
+
+Writing upgrade scripts
+=======================
+
+Upgrade scripts follow a specific tree structure with a naming convention which determines when they
+are executed.
+
+The structure of an upgrade script path is :file:`$module/migrations/$version/{pre,post,end}-*.py`,
+where `$module` is the module for which the script will run, `$version` is the full version of the
+module (including Odoo's major version and the module's minor version) and `{pre|post|end}-*.py` is
+the file that needs to be executed. The file's name will determine the :ref:`phase
+<upgrade-scripts/phases>` and order in which it is executed for that module and version.
+
+.. note::
+   Upgrade scripts are only executed when the module is being updated. Therefore, the
+   module's minor version set in the `$version` directory needs to be higher than the module's
+   installed version and equal or lower to the updated version of the module.
+
+.. example::
+
+   Directory structure of an upgrade script for a custom module named `awesome_partner` upgraded
+   to version `2.0` on Odoo 17.
+
+   .. code-block:: text
+
+      awesome_partner/
+      |-- migrations/
+      |   |-- 17.0.2.0/
+      |   |   |-- pre-exclamation.py
+
+   Two upgrade scripts examples with the content of the :file:`pre-exclamation.py`, file adding
+   "!" at the end of partners' names:
+
+   .. code-block:: python
+
+      import logging
+
+      _logger = logging.getLogger(__name__)
+
+
+      def migrate(cr, version):
+          cr.execute("UPDATE res_partner SET name = name || '!'")
+          _logger.info("Updated %s partners", cr.rowcount)
+
+   .. code-block:: python
+
+      import logging
+      from odoo.upgrade import util
+
+      _logger = logging.getLogger(__name__)
+
+
+      def migrate(cr, version):
+          env = util.env(cr)
+
+          partners = env["res.partner"].search([])
+          for partner in partners:
+              partner.name += "!"
+
+          _logger.info("Updated %s partners", len(partners))
+
+   Note that in the second example, the script takes advantage of the :doc:`./upgrade_utils` to
+   access the ORM. Check the documentation to find out more about this library.
+
+.. _upgrade-scripts/phases:
+
+Phases of upgrade scripts
+=========================
+
+The upgrade process consists of three phases for each version of each module:
+
+  #. The pre-phase, before the module is loaded.
+  #. The post-phase, after the module and its dependencies are loaded and updated.
+  #. The end-phase, after all modules have been loaded and updated for that version.
+
+Upgrade scripts are grouped according to the first part of their filenames into the corresponding
+phase. Within each phase, the files are executed according to their lexical order.
+
+.. admonition:: Execution order of example scripts for one module in one version
+
+   #. :file:`pre-10-do_something.py`
+   #. :file:`pre-20-something_else.py`
+   #. :file:`post-do_something.py`
+   #. :file:`post-something.py`
+   #. :file:`end-01-migrate.py`
+   #. :file:`end-migrate.py`

content/developer/reference/upgrade_utils.rst

@@ -0,0 +1,279 @@
+=============
+Upgrade utils
+=============
+
+`Upgrade utils <https://github.com/odoo/upgrade-util/>`_ is a library that contains helper functions
+to facilitate the writing of upgrade scripts. This library, used by Odoo for the upgrade scripts of
+standard modules, provides reliability and helps speed up the upgrade process:
+
+- The helper functions help make sure the data is consistent in the database.
+- It takes care of indirect references of the updated records.
+- Allows calling functions and avoid writing code, saving time and reducing development risks.
+- Helpers allow to focus on what is important for the upgrade and not think of details.
+
+Installation
+============
+
+Clone the `Upgrade utils repository <https://github.com/odoo/upgrade-util/>`_ locally and start
+``odoo`` with the ``src`` directory prepended to the ``--upgrade-path`` option.
+
+.. code-block:: console
+
+   $ ./odoo-bin --upgrade-path=/path/to/upgrade-util/src,/path/to/other/upgrade/script/directory [...]
+
+On platforms where you do not manage Odoo yourself, you can install this library via `pip`:
+
+.. code-block:: console
+
+   $ python3 -m pip install git+https://github.com/odoo/upgrade-util@master
+
+On `Odoo.sh <https://www.odoo.sh/>`_ it is recommended to add it to the :file:`requirements.txt` of
+the custom repository. For this, add the following line inside the file::
+
+   odoo_upgrade @ git+https://github.com/odoo/upgrade-util@master
+
+Using Upgrade utils
+===================
+
+Once installed, the following packages are available for the upgrade scripts:
+
+- :mod:`odoo.upgrade.util`: the helper itself.
+- :mod:`odoo.upgrade.testing`: base TestCase classes.
+
+To use it in upgrade scripts, simply import it:
+
+.. code-block:: python
+
+   from odoo.upgrade import util
+
+
+   def migrate(cr, version):
+      # Rest of the script
+
+Now, the helper functions are available to be called through ``util``.
+
+Util functions
+==============
+
+Upgrade utils provides many useful functions to ease the upgrade process. Here, we describe some
+of the most useful ones. Refer to the `util folder
+<https://github.com/odoo/upgrade-util/tree/master/src/util>`_ for the comprehensive declaration of
+helper functions.
+
+.. note::
+
+   All util functions receive :attr:`cr` as a parameter. This refers to the database cursor. Pass
+   the one received as a parameter in :meth:`migrate`.
+
+Fields
+------
+
+.. `[source] <https://github.com/odoo/upgrade-util/blob/master/src/util/fields.py#L91>`_
+.. method:: remove_field(cr, model, fieldname, cascade=False, drop_column=True, skip_inherit=())
+
+   Remove a field and its references from the database.
+
+   :param str model: model name of the field to remove
+   :param str fieldname: name of the field to remove
+   :param bool cascade: whether the field's column and inheritance are removed in ``CASCADE``
+   :param bool drop_column: whether the field's column is dropped
+   :param list(str) or str skip_inherit: list of models whose field's inheritance is skipped.
+      Use ``"*"`` to skip all inheritances
+
+.. `[source] <https://github.com/odoo/upgrade-util/blob/master/src/util/fields.py#L362>`_
+.. method:: rename_field(cr, model, old, new, update_references=True, domain_adapter=None, skip_inherit=())
+
+   Rename a field and its references from ``old`` to ``new``.
+
+   :param str model: model name of the field to rename
+   :param str old: current name od the field to rename
+   :param str new: new name od the field to rename
+   :param bool update_references: whether all references of field ``old`` to ``new`` are replaced
+      in: ``ir_filters``, ``ir_exports_line``, ``ir_act_server``, ``mail_alias``,
+      ``ir_ui_view_custom (dashboard)``, ``domains (using "domain_adapter")``, ``related fields``
+   :param function domain_adapter: function that takes three arguments and returns a domain that
+      substitutes the original leaf: ``(leaf: Tuple[str,str,Any], in_or: bool, negated: bool)`` ->
+      ``List[Union[str,Tuple[str,str,Any]]]``
+   :param list(str) or str skip_inherit: list of models whose field's inheritance is skipped.
+      Use ``"*"`` to skip all inheritances
+
+.. `[source] <https://github.com/odoo/upgrade-util/blob/master/src/util/fields.py#L337>`_
+.. method:: move_field_to_module(cr, model, fieldname, old_module, new_module, skip_inherit=())
+
+   Move a field's reference in ``ir_model_data`` table from ``old_module`` to ``new_module``.
+
+   :param str model: model name of the field to move
+   :param str fieldname: name of the field to move
+   :param str old_module: current module name of the field to move
+   :param str new_module: new module name of the field to move
+   :param list(str) or str skip_inherit: list of models whose field's inheritance is skipped.
+      Use ``"*"`` to skip all inheritances
+
+Models
+------
+
+.. `[source] <https://github.com/odoo/upgrade-util/blob/master/src/util/models.py#L53>`_
+.. method:: remove_model(cr, model, drop_table=True, ignore_m2m=())
+
+   Remove a model and its references from the database.
+
+   :param str model: name of the model to remove
+   :param bool drop_table: whether the model's table is dropped
+   :param list(str) or str ignore_m2m: list of m2m tables ignored to remove. Use ``"*"`` to ignore
+      all m2m tables
+
+.. `[source] <https://github.com/odoo/upgrade-util/blob/master/src/util/models.py#L203>`_
+.. method:: rename_model(cr, old, new, rename_table=True)
+
+   Rename a model and its references from ``old`` to ``new``.
+
+   :param str old: current name of the model to rename
+   :param str new: new name of the model to rename
+   :param bool rename_table: whether the model's table is renamed
+
+.. `[source] <https://github.com/odoo/upgrade-util/blob/master/src/util/models.py#L323>`_
+.. method:: merge_model(cr, source, target, drop_table=True, fields_mapping=None, ignore_m2m=())
+
+   Merge the references from ``source`` model into ``target`` model and removes ``source`` model and
+   its references. By default, only the fields with the same name in both models are mapped.
+
+   .. warning::
+      This function does not move the records from ``source`` model to ``target`` model.
+
+   :param str source: name of the source model of the merge
+   :param str target: name of the destination model of the merge
+   :param bool drop_table: whether the source model's table is dropped
+   :param dict fields_mapping: Dictionary ``{"source_model_field_1": "target_model_field_1", ...}``
+      mapping fields with different names on both models
+   :param list(str) or str ignore_m2m: list of m2m tables ignored to remove from source model.
+
+Modules
+-------
+
+.. `[source] <https://github.com/odoo/upgrade-util/blob/master/src/util/modules.py#L218>`_
+.. method:: remove_module(cr, module)
+
+   Uninstall and remove a module and its references from the database.
+
+   :param str module: name of the module to remove
+
+.. `[source] <https://github.com/odoo/upgrade-util/blob/master/src/util/modules.py#L263>`_
+.. method:: rename_module(cr, old, new)
+
+   Rename a module and its references from ``old`` to ``new``.
+
+   :param str old: current name of the module to rename
+   :param str new: new name of the module to rename
+
+.. `[source] <https://github.com/odoo/upgrade-util/blob/master/src/util/modules.py#L323>`_
+.. method:: merge_module(cr, old, into, update_dependers=True)
+
+   Move all references of module ``old`` into module ``into``.
+
+   :param str old: name of the source module of the merge
+   :param str into: ame of the destination module of the merge
+   :param bool update_dependers: whether the dependencies of modules that depends on ``old`` are
+      updated
+
+ORM
+---
+
+.. `[source] <https://github.com/odoo/upgrade-util/blob/master/src/util/orm.py#L43>`_
+.. method:: env(cr)
+
+   Create a new environment from the cursor.
+
+   .. warning::
+      This function does NOT empty the cache maintained on the cursor for superuser with an empty
+      environment. A call to `invalidate_cache` will most probably be necessary every time you
+      directly modify something in database.
+
+   :return: The new environment
+   :rtype: :class:`~odoo.api.Environment`
+
+.. `[source] <https://github.com/odoo/upgrade-util/blob/master/src/util/orm.py#L218>`_
+.. method:: recompute_fields(cr, model, fields, ids=None, logger=_logger, chunk_size=256, strategy="auto")
+
+   Recompute field values. Possible strategies to process the recomputation:
+
+   - ``flush``: Flush the recomputation when it's finished
+   - ``commit``: Commit the recomputation when it's finished
+   - ``auto``: The function chooses the best alternative based on the number of records to recompute
+     and the fields traceability
+
+   :param str model:  model name of the field(s) to recompute
+   :param list(str) fields: list of field names to recompute
+   :param list(int) ids: list of record IDs to recompute
+   :param logger: Logger used to print the progress of the function
+   :type logger: :class:`logging.Logger`
+   :param int chunk_size: size of the chunk used to split the records for better processing
+   :param str strategy: strategy used to process the recomputation
+
+Records
+-------
+
+.. `[source] <https://github.com/odoo/upgrade-util/blob/master/src/util/records.py#L612>`_
+.. method:: ref(cr, xmlid)
+
+   Return the id corresponding to the given :term:`xml_id <external identifier>`.
+
+   :param str xml_id: Record xml_id, under the format ``<module.id>``
+   :return: Found record id, if any
+   :rtype: int or `None`
+
+.. `[source] <https://github.com/odoo/upgrade-util/blob/master/src/util/records.py#L281>`_
+.. method:: remove_record(cr, name)
+
+   Remove a record and its references corresponding to the given
+   :term:`xml_id <external identifier>`.
+
+   :param str name: record xml_id, under the format ``<module.id>``
+
+.. `[source] <https://github.com/odoo/upgrade-util/blob/master/src/util/records.py#L548>`_
+.. method:: rename_xmlid(cr, old, new, noupdate=None, on_collision="fail")
+
+   Rename the :term:`external Identifier` of a record. Possible actions to take if the external
+   Identifier already exists on the database:
+
+   - ``fail``: raise ``MigrationError`` and prevent renaming
+   - ``merge``: renames the external Identifier and removes the old one
+
+   :param str old: current xml_id of the record, under the format ``<module.id>``
+   :param str new: new xml_id of the record, under the format ``<module.id>``
+   :param bool noupdate: value to set on the ir_model_data record ``noupdate`` field
+   :param str on_collision: action to take if the xml_id already exists
+
+.. `[source] <https://github.com/odoo/upgrade-util/blob/master/src/util/records.py#L652>`_
+.. method:: ensure_xmlid_match_record(cr, xmlid, model, values)
+
+   Match a record with an xmlid by creating or updating the external identifier.
+
+   This function is useful when migrating in-database records into a custom module, to create the
+   record's xmlid before the module is updated and avoid duplication.
+
+   :param str xmlid: record xml_id, under the format ``<module.id>``
+   :param str model: model name of the record
+   :param dict values: Dictionary ``{"fieldname_1": "value_1", ...}`` mapping fields and values to
+      search for the record to update. For example:
+
+      .. code-block:: python
+
+         values = {"id": 123}
+         values = {"name": "INV/2024/0001", company_id: 1}
+
+   :return: the :term:`xml_id <external identifier>` of the record.
+   :rtype: str
+
+.. `[source] <https://github.com/odoo/upgrade-util/blob/master/src/util/records.py#L720>`_
+.. method:: update_record_from_xml(cr, xmlid, reset_write_metadata=True, force_create=True, from_module=None, reset_translations=())
+
+   Update a record based on its definition in the :doc:`/developer/reference/backend/data`.
+
+   Useful to update ``noupdate`` records, in order to reset them for the upgraded version.
+
+   :param str xmlid: record xml_id, under the format ``<module.id>``
+   :param bool reset_write_metadata: whether the metadata before the record update is kept
+   :param bool force_create: whether the record is created if it does not exist
+   :param str from_module: name of the module from which to update the record. Useful when the
+      record is rewritten in another module.
+   :param set of str reset_translations: set of field names whose translations get reset

content/developer/tutorials/unit_tests.rst

@@ -48,7 +48,7 @@ Before knowing how to write tests, we need to know how to run them.
                         specifies if we want to include or exclude tests
                         matching this spec. The tag will match tags added on a
                         class with a @tagged decorator (all Test classes have
-                        'standard' and 'at_install' tags until explicitly
+                        'standard' and 'post_install' tags until explicitly
                         removed, see the decorator documentation). '*' will
                         match all tags. If tag is omitted on include mode, its
                         value is 'standard'. If tag is omitted on exclude
@@ -175,17 +175,16 @@ coming from modules your module doesn't depend on.
 
 .. code-block:: python
 
-  from odoo.tests.common import TransactionCase
-  from odoo.tests import tagged
+  from odoo.tests import tagged, TransactionCase
 
   # 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`
+  @tagged('post_install')  # this is the default
   class PostInstallTestCase(TransactionCase):
       def test_01(self):
           ...
 
-  @tagged('at_install')  # this is the default
+  @tagged('at_install', '-post_install')  # add `at_install` and remove `post_install`
   class AtInstallTestCase(TransactionCase):
       def test_01(self):
           ...
@@ -241,13 +240,12 @@ These test classes are built on top of the ``unittest`` python module.
 
 .. code-block:: python
 
-  from odoo.tests.common import TransactionCase
+  from odoo.tests 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(TransactionCase):
 
       @classmethod

redirects/16.0.txt

@@ -1,6 +1,7 @@
 # applications/finance
 
 applications/finance/accounting/bank/feeds/bank_statements.rst applications/finance/accounting/bank/feeds/transactions.rst            # bank_statements -> transactions
+applications/finance/accounting/bank/reconciliation_models.rst applications/finance/accounting/bank/reconciliation/reconciliation_models.rst
 applications/finance/accounting/others/analytic/usage.rst applications/finance/accounting/reporting/analytic_accounting.rst           # others/analytic/usage --> reporting/analytic_accounting
 applications/finance/accounting/others/analytic/timesheets.rst applications/finance/accounting/reporting/analytic_accounting.rst      # others/analytic/timesheets --> reporting/analytic_accounting
 applications/finance/accounting/others/analytic/purchase_expenses.rst applications/finance/accounting/reporting/analytic_accounting.rst # others/analytic/purchase_expenses --> reporting/analytic_accounting