[IMP] reference: rewrite and move views documentation to user_interface/

The documentation of the views is redone in order to be up to date and
has allowed a better visualization of the task on the modifiers.

task-2495504

closes odoo/documentation#3523

Related: odoo/odoo#104741
Related: odoo/enterprise#35255
Related: odoo/upgrade#4884
Signed-off-by: Julien Castiaux (juc) <juc@odoo.com>

content/developer/tutorials/backend.rst

@@ -56,13 +56,14 @@ Business objects
     Declared as Python classes, these resources are automatically persisted
     by Odoo based on their configuration
 
-:ref:`Object views <reference/views>`
+:doc:`Object views <../reference/user_interface/view_architecture>`
     Definition of business objects UI display
 
 :ref:`Data files <reference/data>`
     XML or CSV files declaring the model metadata :
 
-    * :ref:`views <reference/views>` or :ref:`reports <reference/reports>`,
+    * :doc:`views <../reference/user_interface/view_architecture>` or :ref:`reports
+      <reference/reports>`,
     * configuration data (modules parametrization, :ref:`security rules <reference/security>`),
     * demonstration data
     * and more
@@ -304,7 +305,7 @@ requests, the view with the correct type and the lowest priority will be
 used (so the lowest-priority view of each type is the default view for that
 type).
 
-:ref:`View inheritance <reference/views/inheritance>` allows altering views
+:ref:`View inheritance <reference/view_records/inheritance>` allows altering views
 declared elsewhere (adding or removing content).
 
 Generic view declaration
@@ -398,11 +399,11 @@ Form views can also use plain HTML for more flexible layouts:
    <form string="Idea Form">
        <header>
            <button string="Confirm" type="object" name="action_confirm"
-                   states="draft" class="oe_highlight" />
+                   invisible="state != 'draft'" class="oe_highlight" />
            <button string="Mark as done" type="object" name="action_done"
-                   states="confirmed" class="oe_highlight"/>
+                   invisible="state != 'confirmed'" class="oe_highlight"/>
            <button string="Reset to draft" type="object" name="action_draft"
-                   states="confirmed,done" />
+                   invisible="state not in ['confirmed', 'done']" />
            <field name="state" widget="statusbar"/>
        </header>
        <sheet>
@@ -1288,7 +1289,7 @@ A report is a combination two elements:
      the *report* contextual menu rather than the *action* one. There is no
      technical difference but putting elements in the right place helps users.
 
-* A standard :ref:`QWeb view <reference/views/qweb>` for the actual report:
+* A standard :ref:`QWeb view <reference/view_architecture/qweb>` for the actual report:
 
   .. code-block:: xml
 

content/developer/tutorials/define_module_data.rst

@@ -19,8 +19,9 @@ Master data is usually part of the technical or business requirements for the mo
 words, such data is often necessary for the module to work properly. This data will always be
 installed when installing the module.
 
-We already met technical data previously since we have defined :ref:`views <reference/views>` and
-:ref:`actions <reference/actions>`. Those are one kind of master data.
+We already met technical data previously since we have defined :doc:`views
+<../reference/user_interface/view_records>` and :doc:`actions <../reference/backend/actions>`. Those
+are one kind of master data.
 
 On top of technical data, business data can be defined, e.g. countries, currencies, units of measure,
 as well as complete country localization (legal reports, tax definitions, chart of account), and much

content/developer/tutorials/getting_started/01_architecture.rst

@@ -64,13 +64,14 @@ An Odoo module **can** contain a number of elements:
     these classes are automatically mapped to database columns thanks to the
     :abbr:`ORM (Object-Relational Mapping)` layer.
 
-:ref:`Object views <reference/views>`
+:doc:`Object views <../../reference/user_interface/view_architecture>`
     Define UI display
 
 :ref:`Data files <reference/data>`
     XML or CSV files declaring the model data:
 
-    * :ref:`views <reference/views>` or :ref:`reports <reference/reports>`,
+    * :doc:`views <../../reference/user_interface/view_architecture>` or
+      :ref:`reports <reference/reports>`,
     * configuration data (modules parametrization, :ref:`security rules <reference/security>`),
     * demonstration data
     * and more

content/developer/tutorials/getting_started/06_firstui.rst

@@ -47,7 +47,7 @@ Actions
 =======
 
 **Reference**: the documentation related to this topic can be found in
-:ref:`reference/actions`.
+:doc:`../../reference/backend/actions`.
 
 .. note::
 

content/developer/tutorials/getting_started/07_basicviews.rst

@@ -23,7 +23,7 @@ List
 ====
 
 **Reference**: the documentation related to this topic can be found in
-:ref:`reference/views/list`.
+:ref:`reference/view_architecture/list`.
 
 .. note::
 
@@ -72,7 +72,7 @@ Form
 ====
 
 **Reference**: the documentation related to this topic can be found in
-:ref:`reference/views/form`.
+:ref:`reference/view_architecture/form`.
 
 .. note::
 
@@ -134,7 +134,7 @@ Search
 ======
 
 **Reference**: the documentation related to this topic can be found in
-:ref:`reference/views/search`.
+:ref:`reference/view_architecture/search`.
 
 .. note::
 
@@ -154,8 +154,9 @@ Search
 
 Search views are slightly different from the list and form views since they don't display
 *content*. Although they apply to a specific model, they are used to filter
-other views' content (generally aggregated views such as :ref:`reference/views/list`).
-Beyond the difference in use case, they are defined the same way.
+other views' content (generally aggregated views such as
+:ref:`reference/view_architecture/list`). Beyond the difference in use case, they are
+defined the same way.
 
 Their root element is ``<search>``. The most basic version of this view simply
 lists all the fields for which a shortcut is desired:

content/developer/tutorials/getting_started/10_actions.rst

@@ -20,7 +20,7 @@ Action Type
 ===========
 
 **Reference**: the documentation related to this topic can be found in
-:ref:`reference/actions` and :ref:`reference/exceptions`.
+:doc:`../../reference/backend/actions` and :ref:`reference/exceptions`.
 
 .. note::
 

content/developer/tutorials/getting_started/12_sprinkles.rst

@@ -16,7 +16,8 @@ This chapter covers a very small subset of what can be done in the views. Do not
 read the reference documentation for a more complete overview.
 
 **Reference**: the documentation related to this chapter can be found in
-:ref:`reference/views`.
+:doc:`../../reference/user_interface/view_records` and
+:doc:`../../reference/user_interface/view_architecture`.
 
 Inline Views
 ============
@@ -271,41 +272,41 @@ behavior customizations, we can add the ``options`` attribute to several field w
 In :ref:`tutorials/getting_started/06_firstui`, we saw that reserved fields were used for
 specific behaviors. For example, the ``active`` field is used to automatically filter out
 inactive records. We added the ``state`` as a reserved field as well. It's now time to use it!
-A ``state`` field is used in combination with a ``states`` attribute in the view to display
+A ``state`` field is used in combination with a ``invisible`` attribute in the view to display
 buttons conditionally.
 
 .. exercise:: Add conditional display of buttons.
 
-    Use the ``states`` attribute to display the header buttons conditionally as depicted
+    Use the ``invisible`` attribute to display the header buttons conditionally as depicted
     in this section's **Goal** (notice how the 'Sold' and 'Cancel' buttons change when the state is modified).
 
-    Tip: do not hesitate to search for ``states=`` in the Odoo XML files for some examples.
+    Tip: do not hesitate to search for ``invisible=`` in the Odoo XML files for some examples.
 
 More generally, it is possible to make a field ``invisible``, ``readonly`` or ``required`` based
-on the value of other fields thanks to the ``attrs`` attribute. Note that ``invisible`` can also be applied
-to other elements of the view such as ``button`` or ``group``.
+on the value of other fields. Note that ``invisible`` can also be appliedto other elements of
+the view such as ``button`` or ``group``.
 
-The ``attrs`` is a dictionary with the property as a key and a domain as a value. The domain gives
-the condition in which the property applies. For example:
+``invisible``, ``readonly`` or ``required`` can have ``True``, ``False`` or a domain as value.
+The domain gives the condition in which the property applies. For example:
 
 .. code-block:: xml
 
     <form>
-        <field name="description" attrs="{'invisible': [('is_partner', '=', False)]}"/>
+        <field name="description" invisible="not is_partner"/>
         <field name="is_partner" invisible="1"/>
     </form>
 
 This means that the ``description`` field is invisible when ``is_partner`` is ``False``. It is
-important to note that a field used in an ``attrs`` **must** be present in the view. If it
+important to note that a field used in ``invisible`` **must** be present in the view. If it
 should not be displayed to the user, we can use the ``invisible`` attribute to hide it.
 
-.. exercise:: Use ``attrs``.
+.. exercise:: Use ``invisible``.
 
     - Make the garden area and orientation invisible in the ``estate.property`` form view when
       there is no garden.
     - Make the 'Accept' and 'Refuse' buttons invisible once the offer state is set.
     - Do not allow adding an offer when the property state is 'Offer Accepted', 'Sold' or
-      'Canceled'. To do this use the ``readonly`` ``attrs``.
+      'Canceled'. To do this use the ``readonly`` attribute.
 
 .. warning::
 
@@ -385,7 +386,7 @@ Search
 ------
 
 **Reference**: the documentation related to this section can be found in
-:ref:`reference/views/search` and :ref:`reference/views/search/defaults`.
+:ref:`reference/view_architecture/search` and :ref:`reference/view_architecture/search/defaults`.
 
 .. note::
 

content/developer/tutorials/getting_started/13_inheritance.rst

@@ -166,7 +166,7 @@ View Inheritance
 ================
 
 **Reference**: the documentation related to this topic can be found in
-:ref:`reference/views/inheritance`.
+:ref:`reference/view_records/inheritance`.
 
 .. note::
 

content/developer/tutorials/getting_started/15_qwebintro.rst

@@ -25,7 +25,7 @@ Concrete Example: A Kanban View
 ===============================
 
 **Reference**: the documentation related to this topic can be found in
-:ref:`reference/views/kanban`.
+:ref:`reference/view_architecture/kanban`.
 
 .. note::
 
@@ -111,7 +111,7 @@ it is possible to add it outside of the ``<templates>`` element.
     Refer to the **Goal** of the section for a visual example.
 
 Let's give the final touch to our view: the properties must be grouped by type by default. You
-might want to have a look at the various options described in :ref:`reference/views/kanban`.
+might want to have a look at the various options described in :ref:`reference/view_architecture/kanban`.
 
 .. exercise:: Add default grouping.
 

content/developer/tutorials/master_odoo_web_framework/01_fields_and_views.rst

@@ -166,7 +166,7 @@ whenever it is set to `true`.
 .. seealso::
    - `Example: A field inheriting another
      <{GITHUB_PATH}/addons/account/static/src/components/account_type_selection>`_
-   - :ref:`Documentation on xpath <reference/views/inheritance>`
+   - :ref:`Documentation on xpath <reference/view_records/inheritance>`
 
 4. Message for some customers
 =============================

content/developer/tutorials/pdf_reports.rst

@@ -259,7 +259,7 @@ Report Inheritance
       :align: center
       :alt: An inherited report
 
-Inheritance in QWeb uses the same ``xpath`` elements as :ref:`views inheritance <reference/views/inheritance>`.
+Inheritance in QWeb uses the same ``xpath`` elements as :ref:`views inheritance <reference/view_records/inheritance>`.
 A QWeb template refers to its parent template in a different way though. It is even easier to do by just adding
 the ``inherit_id`` attribute to the ``template`` element and setting it equal to the *module.parent_template_id*.
 

content/developer/tutorials/web.rst

@@ -535,7 +535,7 @@ characteristics:
 .. note::
    The rationale behind using QWeb instead of existing javascript template
    engines is the extensibility of pre-existing (third-party) templates, much
-   like Odoo :ref:`views <reference/views>`.
+   like Odoo :doc:`views <../reference/user_interface/view_records>`.
 
    Most javascript template engines are text-based which precludes easy
    structural extensibility where an XML-based templating engine can be
@@ -1649,7 +1649,7 @@ Existing web components
 The Action Manager
 ------------------
 
-In Odoo, many operations start from an :ref:`action <reference/actions>`:
+In Odoo, many operations start from an :doc:`action <../reference/backend/actions>`:
 opening a menu item (to a view), printing a report, ...
 
 Actions are pieces of data describing how a client should react to the
@@ -1664,7 +1664,7 @@ Using the Action Manager
 ~~~~~~~~~~~~~~~~~~~~~~~~
 
 The action manager can be invoked explicitly from javascript code by creating
-a dictionary describing :ref:`an action <reference/actions>` of the right
+a dictionary describing :doc:`an action <../reference/backend/actions>` of the right
 type, and calling an action manager instance with it.
 
 :func:`~odoo.Widget.do_action` is a shortcut of :class:`~odoo.Widget`
@@ -1819,7 +1819,7 @@ multiple views depending on the original action's requirements:
 The Views
 ~~~~~~~~~
 
-Most :ref:`Odoo views <reference/views>` are implemented through a subclass
+Most :doc:`Odoo views <../reference/user_interface/view_records>` are implemented through a subclass
 of :class:`odoo.web.View` which provides a bit of generic basic structure
 for handling events and displaying model information.
 

content/developer/tutorials/website.rst

@@ -622,7 +622,7 @@ and having opened a listing of teachers. From the listing it is possible to
 view.
 
 If there is no definition of how to present records (a
-:ref:`view <reference/views>`) Odoo will automatically create a basic one
+:doc:`view <../reference/user_interface/view_records>`) Odoo will automatically create a basic one
 on-the-fly. In our case it works for the "list" view for now (only displays
 the teacher's name) but in the "form" view the HTML ``biography`` field is
 displayed side-by-side with the ``name`` field and not given enough space.