diff --git a/content/developer/reference/backend.rst b/content/developer/reference/backend.rst index 7b795e534..cd56eca9c 100644 --- a/content/developer/reference/backend.rst +++ b/content/developer/reference/backend.rst @@ -10,9 +10,8 @@ Python framework backend/orm backend/data backend/actions - backend/views - backend/module backend/reports + backend/module backend/security backend/performance backend/testing diff --git a/content/developer/reference/backend/actions.rst b/content/developer/reference/backend/actions.rst index c8097bf58..b8e20f137 100644 --- a/content/developer/reference/backend/actions.rst +++ b/content/developer/reference/backend/actions.rst @@ -1,6 +1,3 @@ - -.. _reference/actions: - ======= Actions ======= @@ -65,7 +62,7 @@ Window Actions (``ir.actions.act_window``) ========================================== The most common action type, used to present visualisations of a model through -:ref:`views `: a window action defines a set of view types +:doc:`views <../user_interface/view_records>`: a window action defines a set of view types (and possibly specific views) for a model (and possibly specific record of the model). diff --git a/content/developer/reference/backend/data.rst b/content/developer/reference/backend/data.rst index a10359ca5..b47d67ae6 100644 --- a/content/developer/reference/backend/data.rst +++ b/content/developer/reference/backend/data.rst @@ -236,7 +236,7 @@ Defines an ``ir.ui.menu`` record with a number of defaults and fallbacks: ``template`` ------------ -Creates a :ref:`QWeb view ` requiring only the ``arch`` +Creates a :ref:`QWeb view ` requiring only the ``arch`` section of the view, and allowing a few *optional* attributes: ``id`` diff --git a/content/developer/reference/backend/views.rst b/content/developer/reference/backend/views.rst deleted file mode 100644 index ec3ca5f72..000000000 --- a/content/developer/reference/backend/views.rst +++ /dev/null @@ -1,2486 +0,0 @@ - -.. _reference/views: - -===== -Views -===== - -Views are what define how records should be displayed to end-users. They are specified in XML which -means that they can be edited independently from the models that they represent. They are flexible -and allow a high level of customization of the screens that they control. There exist various types -of views. Each of them represents a mode of visualization: *form*, *list*, *kanban*, etc. - -.. todo:: Build doc of ir_ui_view.py ? - -.. _reference/views/structure: - -Generic structure -================= - -Basic views generally share the common structure defined below. Placeholders are denoted in all -caps. - -.. code-block:: xml - - - NAME - MODEL - - - - - - - -Fields -====== - -View objects expose a number of fields. They are optional unless specified otherwise. - -* ``name`` (mandatory) :class:`~odoo.fields.Char` - - Only useful as a mnemonic/description of the view when looking for one in a list of some sort. - -* ``model`` :class:`~odoo.fields.Char` - - The model linked to the view, if applicable. - -* ``priority`` :class:`~odoo.fields.Integer` - - When a view is requested by ``(model, type)``, the view matching the model and - the type, with the lowest priority will be returned (it is the default view). - - It also defines the order of views application during :ref:`view - inheritance `. - -* ``groups_id`` :class:`~odoo.fields.Many2many` -> :class:`odoo.addons.base.models.res_users.Groups` - - The groups allowed to use/access the current view. - - If the view extends an existing view, the extension will only be applied - for a given user if the user has access to the provided ``groups_id``. - -* ``arch`` :class:`~odoo.fields.Text` - - The description of the view layout. - -Attributes -========== - -.. todo:: - - view attributes & view element attributes - attrs & states attributes are missing generic information - -The different view types have a wide variety of attributes allowing customizations of -the generic behaviors. Some main attributes will be explained here. They do not all have -an impact on all view types. - -.. note:: The current context and user access rights may also impact the view abilities. - -.. todo:: info on create/... in the context ? - -* ``create`` - - Disable/enable record creation on the view. - -* ``edit`` (``form`` & ``list`` & ``gantt``) - - Disable/enable record editing on the view. - -* ``delete`` (``form`` & ``list``) - - Disable/enable record deletion on the view through the **Action** dropdown. - -* ``duplicate`` (``form``) - - Disable/enable record duplication on the view through the **Action** dropdown. - -* ``decoration-{$name}`` (``list`` & ``gantt``) - - Define a conditional display of a record in the style of a row's text based on the corresponding - record's attributes. - - Values are Python expressions. For each record, the expression is evaluated - with the record's attributes as context values and if ``true``, the - corresponding style is applied to the row. Here are some of the other values - available in the context: - - * ``uid``: the id of the current user, - * ``today``: the current local date as a string of the form ``YYYY-MM-DD``, - * ``now``: same as ``today`` with the addition of the current time. - This value is formatted as ``YYYY-MM-DD hh:mm:ss``. - - .. code-block:: xml - - - - - - .. warning:: - Supported values differ for the two view types. The Gantt view only supports ``success``, - ``info``, ``warning``, ``danger`` and ``secondary`` displays. The list view supports ``bf``, - ``it``, ``success``, ``info``, ``warning``, ``danger``, ``muted`` and ``primary`` displays. - -* ``sample`` (``kanban`` & ``list`` & ``gantt`` & ``graph`` & ``pivot`` & ``cohort``) - - Populate the view with a set of sample records if none are found for the current model. - This attribute is false by default. - - These fake records will have heuristics for certain field names/models. For example, - a field 'display_name' on the model 'res.users' will be populated with sample people names - while an 'email' field will be in the form 'firstname.lastname@sample.demo'. - - The user will not be able to interact with these data and they will be discarded as soon as - an action is performed (record created, column added, etc.) - -* ``banner_route`` - a route address to be fetched and prepended to the view. - - If this attribute is set, the - :ref:`controller route url` will be fetched and - displayed above the view. The json response from the controller should - contain an "html" key. - - If the html contains a stylesheet tag, it will be - removed and appended to . - - To interact with the backend you can use tags. Please take - a look at the documentation of the _onActionClicked method of - AbstractController (*addons/web/static/src/js/views/abstract_controller.js*) - for more details. - - Only views extending AbstractView and AbstractController can use this - attribute, like :ref:`reference/views/form`, :ref:`reference/views/kanban`, - :ref:`reference/views/list`, ... - - Example: - - .. code-block:: xml - - - - .. code-block:: python - - class MyController(odoo.http.Controller): - @http.route('/module_name/hello', auth='user', type='json') - def hello(self): - return { - 'html': """ -
- -

hello, world

-
""" - } - -.. todo:: Views main content section, with field, group & separator ? - -* ``class`` - optional string containing some classes to set on the root node of the view. - -* ``js_class`` - optional component class to use to render the view. - If set, the ``js_class`` attribute will also be used to apply a css class to the - root node of the view. For example, if ``js_class`` is set to ``my-custom-kanban``, - then the class ``o_my-custom-kanban_view`` will be applied on the root node. - -.. _reference/views/inheritance: - -Inheritance -=========== - -Inheritance fields ------------------- - -The two following :class:`~odoo.addons.base.ir_ui_view.View` fields are used to specify -inherited views. - -* ``inherit_id`` :class:`~odoo.fields.Many2one` - - the current view's parent view, unset by default. Specify the parent using - the `ref` attribute: - - .. code-block:: xml - - - -* ``mode`` :class:`~odoo.fields.Selection`: `extension / primary` - - inheritance mode, ``extension`` by default if ``inherit_id`` is set, - ``primary`` otherwise. - - An example of where you would want to override ``mode`` while using - ``inherit_id`` is delegation inheritance. - In that case your derived model will be separate from its parent and views - matching with one won't match with the other. Suppose you inherit from a view - associated with the parent model and want to customize the derived view to - show data from the derived model. The ``mode`` of the derived view needs to - be set to ``primary``, because it's the base (and maybe only) view for that - derived model. Otherwise the :ref:`view matching ` - rules won't apply. - -.. _reference/views/inheritance/view-matching: - -View matching -------------- - -* if a view is requested by ``(model, type)``, the view with the right model - and type, ``mode=primary`` and the lowest priority is matched. -* when a view is requested by ``id``, if its mode is not ``primary`` its - *closest* parent with mode ``primary`` is matched. - -View resolution ---------------- - -Resolution generates the final ``arch`` for a requested/matched ``primary`` -view: - -#. if the view has a parent, the parent is fully resolved then the current - view's inheritance specs are applied -#. if the view has no parent, its ``arch`` is used as-is -#. the current view's children with mode ``extension`` are looked up and their - inheritance specs are applied depth-first (a child view is applied, then - its children, then its siblings) - -The result of applying children views yields the final ``arch`` - -.. todo:: NOTE on fields_view_get and link to ORM ? - -Inheritance specs ------------------ - -Inheritance specs are comprised of an element locator, to match -the inherited element in the parent view, and children element that -will be used to modify the inherited element. - -There are three types of element locators for matching a target element: - -* An ``xpath`` element with an ``expr`` attribute. ``expr`` is an XPath_ - expression\ [#hasclass]_ applied to the current ``arch``, the first node - it finds is the match -* a ``field`` element with a ``name`` attribute, matches the first ``field`` - with the same ``name``. All other attributes are ignored during matching -* any other element: the first element with the same name and identical - attributes (ignoring ``position`` and ``version`` attributes) is matched - -.. code-block:: xml - - - - - - - -
-
- -
-
- -The inheritance spec may have an optional ``position`` attribute specifying -how the matched node should be altered: - -.. rst-class:: o-definition-list - -``inside`` (default) - the content of the inheritance spec is appended to the matched node -``replace`` - the content of the inheritance spec replaces the matched node. - Any text node containing only ``$0`` within the contents of the spec will - be replaced by a complete copy of the matched node, effectively wrapping - the matched node. -``after`` - the content of the inheritance spec is added to the matched node's - parent, after the matched node -``before`` - the content of the inheritance spec is added to the matched node's - parent, before the matched node -``attributes`` - the content of the inheritance spec should be ``attribute`` elements - with a ``name`` attribute and an optional body: - - * if the ``attribute`` element has a body, a new attributed named - after its ``name`` is created on the matched node with the - ``attribute`` element's text as value - * if the ``attribute`` element has no body, the attribute named after - its ``name`` is removed from the matched node. If no such attribute - exists, an error is raised - * if the ``attribute`` element has an ``add`` attribute, a ``remove`` attribute, or both, the - value of the matched node's attribute named after ``name`` is recomputed to include the - value(s) of ``add`` (separated by ``separator``) and delete the value(s) of ``remove`` - (separated by ``separator``). If ``separator`` is not provided, ``,`` is used instead. - - .. code-block:: xml - - - 0 - - {'invisible': [('sale_ok', '=', False)], 'readonly': [('editable', '=', False)]} - - - - -``move`` - can be used as a direct child of a inheritance spec - with a ``inside``, ``replace``, ``after`` or ``before`` ``position`` attribute - to move a node. - - .. code-block:: xml - - - - - - - - - - -A view's specs are applied sequentially. - -.. [#hasclass] an extension function is added for simpler matching in QWeb - views: ``hasclass(*classes)`` matches if the context node has - all the specified classes - -Model Commons -============= - -.. currentmodule:: odoo.addons.base.models.ir_ui_view - -Attributes ----------- - -.. autoattribute:: Model._date_name - -Methods -------- - -.. automethod:: Model.get_views -.. automethod:: Model.get_view - -.. _reference/views/types: - -View types -========== - -.. _reference/views/activity: - -Activity --------- - -The Activity view is used to display the activities linked to the records. The -data are displayed in a chart with the records forming the rows and the activity -types the columns. The first cell of each row displays a (customizable, see -``templates``, quite similarly to :ref:`reference/views/kanban`) card representing -the corresponding record. When clicking on others cells, a detailed description -of all activities of the same type for the record is displayed. - -.. warning:: - - The Activity view is only available when the ``mail`` module is installed, - and for the models that inherit from the ``mail.activity.mixin``. - -The root element of the Activity view is ````, it accepts the following -attributes: - -.. rst-class:: o-definition-list - -``string`` (mandatory) - A title, which should describe the view - -Possible children of the view element are: - -.. rst-class:: o-definition-list - -``field`` - declares fields to use in activity *logic*. If the field is simply displayed - in the activity view, it does not need to be pre-declared. - - Possible attributes are: - - .. rst-class:: o-definition-list - - ``name`` (required) - the name of the field to fetch - -``templates`` - defines the :ref:`reference/qweb` templates. Cards definition may be - split into multiple templates for clarity, but activity views *must* define at - least one root template ``activity-box``, which will be rendered once for each - record. - - The activity view uses mostly-standard :ref:`javascript qweb - ` and provides the following context variables - (see :ref:`reference/views/kanban` for more details): - - .. rst-class:: o-definition-list - - ``widget`` - the current :js:class:`ActivityRecord`, can be used to fetch some - meta-information. These methods are also available directly in the - template context and don't need to be accessed via ``widget`` - ``record`` - an object with all the requested fields as its attributes. Each field has - two attributes ``value`` and ``raw_value`` - -.. _reference/views/calendar: - -Calendar --------- - -Calendar views display records as events in a daily, weekly, monthly or yearly -calendar. - -.. note:: By default the calendar view will be centered around the current date - (today). You can pass a specific initial date to the context of the action in - order to set the initial focus of the calendar on the period (see `mode`) around - this date (the context key to use being `initial_date`) - -Their root element is ````. Available attributes on the -calendar view are: - -.. rst-class:: o-definition-list - -``date_start`` (required) - name of the record's field holding the start date for the event -``date_stop`` - name of the record's field holding the end date for the event, if - ``date_stop`` is provided records become movable (via drag and drop) - directly in the calendar -``date_delay`` - alternative to ``date_stop``, provides the duration of the event instead of - its end date (unit: day) -``color`` - name of a record field to use for *color segmentation*. Records in the - same color segment are allocated the same highlight color in the calendar, - colors are allocated semi-randomly. - Displayed the display_name/avatar of the visible record in the sidebar -``form_view_id`` - view to open when the user create or edit an event. Note that if this attribute - is not set, the calendar view will fall back to the id of the form view in the - current action, if any. -``event_open_popup`` - If the option 'event_open_popup' is set to true, then the calendar view will - open events (or records) in a FormViewDialog. Otherwise, it will open events - in a new form view (with a do_action) -``quick_add`` - When a boolean value is passed, enables quick-event creation on click: only - asks the user for a ``name`` (the field to which this values is saved can be - controlled through ``rec_name``) and tries to create a new event with just that - and the clicked event time. Falls back to a full form dialog if the quick - creation fails. This attribute also accepts a form view id, which will be used - instead of the quick create default dialog. -``create_name_field`` - name of the record's field holding the textual representation of the record, - this is used when creating records through the 'quick create' mechanism -``all_day`` - name of a boolean field on the record indicating whether the corresponding - event is flagged as day-long (and duration is irrelevant) -``mode`` - Default display mode when loading the calendar. - Possible attributes are: ``day``, ``week``, ``month``, ``year`` -``scales`` - Comma-separated list of scales to provide. By default, all scales are - available. See mode for possible scale values. -``create``, ``delete`` - allows disabling the corresponding action in the view by setting the - corresponding attribute to ``false`` -```` - declares fields to aggregate or to use in kanban *logic*. If the field is - simply displayed in the calendar cards. - - Fields can have additional attributes: - - .. rst-class:: o-definition-list - - ``invisible`` - use "True" to hide the value in the cards - ``avatar_field`` - only for x2many field, to display the avatar instead of the display_name - in the cards - ``write_model`` and ``write_field`` and ``filter_field`` - you can add a filter and save the result in the defined model, the - filter is added in the sidebar. The ``filter_field`` is optional and allows - you to specify the field that will hold the status of the filter. - ``filters`` and ``color`` - use "True" to add this field in filter in the sidebar. You can specify - a ``color`` field used to colorize the checkbox. - -.. _reference/views/cohort: - -Cohort ------- - -.. raw:: html - - Enterprise feature - -The cohort view is used to display and understand the way some data changes over -a period of time. For example, imagine that for a given business, clients can -subscribe to some service. The cohort view can then display the total number -of subscriptions each month, and study the rate at which client leave the service -(churn). When clicking on a cell, the cohort view will redirect you to a new action -in which you will only see the records contained in the cell's time interval; -this action contains a list view and a form view. - -.. note:: By default the cohort view will use the same list and form views as those - defined on the action. You can pass a list view and a form view - to the context of the action in order to set/override the views that will be - used (the context keys to use being `form_view_id` and `list_view_id`) - -For example, here is a very simple cohort view: - -.. code-block:: xml - - - -The root element of the Cohort view is , it accepts the following -attributes: - -.. rst-class:: o-definition-list - -``string`` (mandatory) - A title, which should describe the view - -``date_start`` (mandatory) - A valid date or datetime field. This field is understood by the view as the - beginning date of a record - -``date_stop`` (mandatory) - A valid date or datetime field. This field is understood by the view as the - end date of a record. This is the field that will determine the churn. - -``disable_linking`` (optional) - Set to ``1`` to prevent from redirecting clicks on cohort cells to list view. - -``mode`` (optional) - A string to describe the mode. It should be either 'churn' or - 'retention' (default). Churn mode will start at 0% and accumulate over time - whereas retention will start at 100% and decrease over time. - -``timeline`` (optional) - A string to describe the timeline. It should be either 'backward' or 'forward' (default). - Forward timeline will display data from date_start to date_stop, whereas backward timeline - will display data from date_stop to date_start (when the date_start is in future / greater - than date_stop). - -``interval`` (optional) - A string to describe a time interval. It should be 'day', 'week', 'month'' - (default) or 'year'. - -``measure`` (optional) - A field that can be aggregated. This field will be used to compute the values - for each cell. If not set, the cohort view will count the number of occurrences. - -```` (optional) - allows to specify a particular field in order to manage it from the available measures, it's - main use is for hiding a field from the selectable measures: - - .. rst-class:: o-definition-list - - ``name`` (mandatory) - the name of the field to use in the view. - ``string`` (optional) - the name that would be used to display the field in the cohort view, overrides the - default python String attribute of the field. - ``invisible`` (optional) - if true, the field will not appear either in the active measures nor in the selectable - measures (useful for fields that do not make sense aggregated, such as fields in different - units, e.g. € and $). - -.. _reference/views/form: - -Form ----- - -Form views are used to display the data from a single record. Their root -element is ``
``. They are composed of regular HTML_ with additional -structural and semantic components. - -Structural components -~~~~~~~~~~~~~~~~~~~~~ - -Structural components provide structure or "visual" features with little -logic. They are used as elements or sets of elements in form views. - -.. rst-class:: o-definition-list - -``notebook`` - defines a tabbed section. Each tab is defined through a ``page`` child - element. Pages can have the following attributes: - - .. rst-class:: o-definition-list - - ``string`` (required) - the title of the tab - ``accesskey`` - an HTML accesskey_ - ``attrs`` - standard dynamic attributes based on record values - - .. note:: Note that ``notebook`` should not be placed within ``group`` - -``group`` - used to define column layouts in forms. By default, groups define 2 columns - and most direct children of groups take a single column. ``field`` direct - children of groups display a label by default, and the label and the field - itself have a colspan of 1 each. - - The number of columns in a ``group`` can be customized using the ``col`` - attribute, the number of columns taken by an element can be customized using - ``colspan``. - - Children are laid out horizontally (tries to fill the next column before - changing row). - - Groups can have a ``string`` attribute, which is displayed as the group's - title -``newline`` - only useful within ``group`` elements, ends the current row early and - immediately switches to a new row (without filling any remaining column - beforehand) -``separator`` - small horizontal spacing, with a ``string`` attribute behaves as a section - title -``sheet`` - can be used as a direct child to ``form`` for a narrower and more responsive - form layout -``header`` - combined with ``sheet``, provides a full-width location above the sheet - itself, generally used to display workflow buttons and status widgets - -Semantic components -~~~~~~~~~~~~~~~~~~~ - -Semantic components tie into and allow interaction with the Odoo -system. Available semantic components are: - -.. rst-class:: o-definition-list - -``button`` - call into the Odoo system, similar to :ref:`list view buttons - `. In addition, the following attribute can be - specified: - - .. rst-class:: o-definition-list - - ``special`` - for form views opened in dialogs: ``save`` to save the record and close the - dialog, ``cancel`` to close the dialog without saving. - ``confirm`` - confirmation message to display (and for the user to accept) before - performing the button's Odoo call (also works in Kanban views). - -``field`` - renders (and allow editing of, possibly) a single field of the current - record. Using several times a field in a form view is supported and the fields - can receive different values for modifiers 'invisible' and 'readonly'. However, - the behavior is not guaranteed when several fields exist with different values - for modifier 'required'. Possible attributes of the field node are: - - .. rst-class:: o-definition-list - - ``name`` (mandatory) - the name of the field to render - ``id`` - the node id. Useful when there are several occurrences of the same field in - the view (see ``label`` component below). Default is the field name. - ``widget`` - fields have a default rendering based on their type - (e.g. :class:`~odoo.fields.Char`, - :class:`~odoo.fields.Many2one`). The ``widget`` attributes allows using - a different rendering method and context. - - .. todo:: list of widgets - - & options & specific attributes (e.g. widget=statusbar - statusbar_visible clickable) - ``options`` - JSON object specifying configuration option for the field's widget - (including default widgets) - ``class`` - HTML class to set on the generated element, common field classes are: - - .. rst-class:: o-definition-list - - ``oe_inline`` - prevent the usual line break following fields and limit their span. - ``oe_left``, ``oe_right`` - floats_ the field to the corresponding direction - ``oe_read_only``, ``oe_edit_only`` - only displays the field in the corresponding form mode - ``oe_avatar`` - for image fields, displays images as "avatar" (square, 90x90 maximum - size, some image decorations) - ``groups`` - only displays the field for specific users - ``on_change`` - calls the specified method when this field's value is edited, can generate - update other fields or display warnings for the user - - .. deprecated:: 8.0 - - Use :func:`odoo.api.onchange` on the model - - ``attrs`` - dynamic meta-parameters based on record values - ``domain`` - for relational fields only, filters to apply when displaying existing - records for selection - ``context`` - for relational fields only, context to pass when fetching possible values - ``readonly`` - display the field in both readonly and edit mode, but never make it - editable - ``required`` - generates an error and prevents saving the record if the field doesn't - have a value - ``nolabel`` - don't automatically display the field's label, only makes sense if the - field is a direct child of a ``group`` element - ``placeholder`` - help message to display in *empty* fields. Can replace field labels in - complex forms. *Should not* be an example of data as users are liable to - confuse placeholder text with filled fields - ``mode`` - for :class:`~odoo.fields.One2many`, display mode (view type) to use for - the field's linked records. One of ``tree``, ``form``, ``kanban`` or - ``graph``. The default is ``tree`` (a list display) - ``help`` - tooltip displayed for users when hovering the field or its label - ``filename`` - for binary fields, name of the related field providing the name of the - file - ``password`` - indicates that a :class:`~odoo.fields.Char` field stores a password and - that its data shouldn't be displayed - ``kanban_view_ref`` - for opening specific kanban view when selecting records from m2o/m2m in mobile - environment - -``label`` - when a ``field`` component isn't placed directly inside a ``group``, or when - its ``nolabel`` attribute is set, the field's label isn't automatically - displayed alongside its value. The ``label`` component is the manual alternative - of displaying the label of a field. Possible attributes are: - - .. rst-class:: o-definition-list - - ``for`` (mandatory) - the reference to the field associated with the label. Can be either the name - of a field, or its id (``id`` attribute set on the ``field``). When there are - several occurrences of the same field in the view, and there are several - ``label`` components associated with these ``field`` nodes, those labels - must have unique ``for`` attributes (in this case referencing the ``id`` - attribute of the corresponding ``field`` nodes). - ``string`` - the label to display. Display the field's label (coming from the field - definition in the model) by default. - ``class`` - same as for ``field`` component. - ``attrs`` - same as for ``field`` component. - - .. _reference/views/form/setting: -``setting`` - The ``setting`` tag is used to declare a setting, an entity visually separated on two panels - (left and right), and used to edit a given field. The first field in the setting is used as the - main field (optional). This field is placed on the left panel (if it's a boolean field) or on the - top of the right panel (otherwise). The field is also used to create the setting label if a - ``string`` is not defined. The ``setting`` tag can also contain more elements (e.g. html), all of - these elements are rendered in the right panel. - - .. rst-class:: o-definition-list - - ``string`` (optional) - The text used as label of the setting. If it's not defined, the first field is used as label. - ``title`` (optional) - The text used as tooltip. - ``help`` (optional) - The help/description of the setting. This text is displayed just below the setting label (with classname ``text-muted``). - ``company_dependent`` (optional) - If this attribute is set to "1" an icon is displayed next to the setting label to explicit - that this setting is company-specific. - ``documentation`` (optional) - If this attribute is set, an icon is added next to the setting label, this icon is a link to the documentation. - Note that you can use relative or absolute path. The relative path is relative to ``https://www.odoo.com/documentation/``, - so it's not necessary to hard-code the server version on the arch anymore. - - .. example:: - .. code-block:: xml - - - - ...More elements - - - -Generic structure -~~~~~~~~~~~~~~~~~ - -.. code-block:: xml - - -
- -
- -
- -
- - - - - - - - - - - - - - - - - - - - -.. todo:: classes for forms - -.. todo:: widgets? - -Settings Form View ------------------- - -The settings form view is a customization of the form view. It's used to centralize all the settings -of Odoo. - -This view differs from a generic form view because it has a search bar, a sidebar and accepts 2 -additional tags: ``app`` and ``block``. It also adds a new parameter to the ``setting`` tag. - -.. rst-class:: o-definition-list - -``app`` - The ``app`` tag is used to declare the application on the settings view. It creates an entry with - its logo on the sidebar of the view. It also acts as delimiter when searching. - - Syntax: - - .. code-block:: xml - - - ... - - - Parameters: - - .. rst-class:: o-definition-list - - ``string`` - The "display" name of the application. - ``name`` - The technical name of the application (the name of the module). - ``logo`` (optional) - The relative path to the logo. If not set, the logo is created using the ``name`` parameter : ``/{name}/static/description/icon.png``. - -``block`` - The ``block`` tag is used to declare a group of settings. This group can have a title and a description/help. - - Syntax: - - .. code-block:: xml - - - ... - - - Parameters: - - .. rst-class:: o-definition-list - - ``title`` (optional) - The title of the block of settings, you can perform research on its text. - ``help`` (optional) - The description/help of the block of settings, you can perform research on its text. - -``setting`` - The definition and all the available parameters of the ``setting`` tag can be found in - the :ref:`setting tag ` definition in the form view. The settings - form view adds the following parameter to the ``setting`` tag: - - .. rst-class:: o-definition-list - - ``type`` (optional) - By default, a setting is visually separated on two panels (left and right), and is used to - edit a given field. By defining ``type='header'``, a special kind of setting is rendered - instead. This setting is used to modify the scope of the other settings. For example, on the - website application, this setting is used to indicate to which website the other settings - apply. The header setting is visually represented as a yellow banner on the top of the screen. - -.. example:: - - .. code-block:: xml - - - - - + +:special: + string_ (optional) chooses from ``save`` or ``cancel`` + + for form views opened in dialogs: ``save`` to save the record and + close the dialog, ``cancel`` to close the dialog without saving. + + .. code-block:: xml + + + + ... + + + .. image:: view_architecture/form_button_box.svg + :class: col-xxl-6 + +container for a title +~~~~~~~~~~~~~~~~~~~~~ + +.. code-block:: xml + + + +
+

+
+ + + +Container for specific rendering to display a :ref:` ` as title. + +.. .................................................................... + +.. _reference/view_architecture/settings: + +Settings Form View +================== + +The settings form view is a customization of the :ref:`form view `. +It's used to centralize all the settings of Odoo. + +This view differs from a generic form view because it has a search bar, a sidebar and accepts 3 +additional tags: ``app``, ``block`` and ``setting``. + +.. example:: + + .. code-block:: xml + + + + +