blog

Different-Types-of-Actions-in-Odoo-blog
News & Events

DIFFERENT TYPES OF USER ACTIONS IN ODOO

The behavior of the system in response to the user actions known as ‘Actions’ in Odoo. these can be user logins, action buttons, invoice or bill selection, etc.

These user actions can also stored in the database or can returned as dictionaries, with button methods.

There are mainly 6 types of Actions in Odoo

  1. Server Actions
  2. Client Actions
  3. Window Actions
  4. URL Actions
  5. Report Actions
  6. Automated Actions

All the user-defined actions in the Odoo database can be assessed from

Settings → Technical → Actions

user-actions-odoo

In the Actions form view, there are 2 mandatory fields, which are:

  1. Name – This represents the name of the action.
  2. Action Type – This shows the type or category of the action.

Apart from the above mandatory fields and also other parameters or attributes which can define an action include:

  1. res_model,
  2. binding_model_id,
  3. binding_view_types,
  4. view_id,

    1. view_ids,
    2. view_mode,
    3. view_type,
    4. search_view_id,
    5. state,
    6. code,
    7. domain,
    8. context,
    9. target, etc.

Server Actions

  • We define these actions as – ir.actions.server
  • These actions work on a base model and offer different actions that can execute automatically.
  • Different actions that a server action can perform include:
  • Execute the Python Code
        • Create a Record
        • Update the Record
        • Execute several Actions
        • Send Email
        • Add Followers
        • Create Next Activity
        • Send an SMS Text Message
      • We can define this action using the following parameters:

        1. id – they gave unique ID to this server action
        2. model – “ir.actions.server”
        3. name – the descriptive name given to the server action which will be displayed in the user interface
        4. model_id/binding_model_id – model to which it applied this server action
        5. binding_view_types – view types for which the action appears in the contextual menu, mostly “list” and/or “form”
        6. state – defines the type of action to be performed. This can be –
          • ‘code’ – to Execute Python Code
          • ‘object_create’ – to Create a Record
          • ‘object_write’ – to Update the Record
          • ‘multi’ – to execute several Actions
          • ‘email’ – to Send Email
          • ‘followers’ – to Add Followers
          • ‘next_activity’ – to Create Next Activity
          • ‘sms’ – to Send SMS Text Message
      • Example – In this, the custom_function () in the purchase_order model will be called when executing the server action.

server-action

Client Actions

    1. We define these actions as – ir.actions.client
    2. Basically, these trigger the actions implemented by the client.
    3. These are I then mapped menu items defined in XML and the corresponding actions to a widget.
    4. We can define this action using the following parameters:
      1. name – descriptive name given to this client action
      2. tag – An arbitrary string that helps to identify the action.
      3. res_model – Refers to the destination model
      4. target: Selection field refers to the type of target window. This can be –
        1. current: Client action will open in the main content area
        2. new: will open in a dialogue/pop-up window.
        3. fullscreen: will open in full-screen mode.
        4. main: open in the main content area without breadcrumbs
    5. Example – first, define an action in XML.

client-action

The next step is to map the custom tag to a widget in JS.

custom-tag

Window Actions

    1. We define these actions as – ir.actions.window
    2. This is one of the most commonly used actions.
    3. This is used to visualize the models with different views, such as tree view, from view, etc.
    4. We can define this action using the following parameters:
      1. name – descriptive name given to this action
      2. res_model – Model for representing this action window.
      3. res_id – It is used to pass the active_id of res_model.
      4. view_mode–List of view types separated by commas(no spaces), such as kanban, tree, and form.
      5. view_id – Provides the default view type that will be open when the action executed. If nothing defined, then it will open the window with the view of the first type defined in the view_mode.
      6. view_ids – We can define specific views for a specific view_mode.
      7. search_view_id – Setting the default search view for the object.
      8. context – Used to pass additional context data to the view.
      9. domain – Condition used to filter the data passed to view.
      10. target : We can define different options for target windows, such as
        1. new – It opens a window with a new address and edit mode (as when creating wizards).
        2. current – It opens the regular form views.
        3. fullscreen – It will open the window in full-screen mode.
        4. main – Without breadcrumb, it opens the main content area.
        5. inline – It will open the window in edit mode.
    5. Example

windows-action

      1. Using this, we can define views for our models in XML.
      1. This can also used inside a button action to return a specific view and can define in PY.

action-act-window

URL Actions

    1. They defined these actions as – ir.actions.act_url
    2. This type of action is used to open a URL, i.e., a website or a web page.
    3. We can define this action using the following parameters:
      1. name – descriptive name given to this action
      2. url – the URL address to open when activating the action
      3. target: Selection field to represent the action target.
        1. new – opens the given URL in a new window/page.
        2. self –replaces the current content with the URL page.
    4. Example – In XML, these can define as:

url-action

In PY, we can define these as:

action-act-url

Report Actions

    1. They defined these actions as – ir.actions.report
    2. This type of action is used to trigger the printing action of a report.

    3. We can define this action using the following parameters:
      1. name – Name of report action.
      2. model – the model of the report.
      3. report_type – qweb-html (for HTML reports) or qweb-pdf (for PDF reports)
      4. report_name – Report name.
      5. print_report_name – python expression defining the name of the report.
      6. binding_model_id – report action will appear in this model’s Print menu
      7. groups_id – Security Groups allowed for the current report.
      8. paperformat_id – Field to specify the paper format for the report.
      9. attachment – Where we can define a python expression (name of the report).
      10. attachment_use : It set to be true when the reports must be generate once and we can reprint the stored report instead of generating it every time.
    4. Example

report-actions

Automated Actions

    1. They define these actions as – ir.cron
    2. This action is used to trigger functions automatically at a certain interval of time.
    3. We can define this action using the following parameters:
      1. name – Name of the automated action (Mainly used in log display)
      2. interval_type – Unit of measure of frequency interval (minutes, hours, days, weeks, months
      3. interval_number – Number of interval_type uom between two executions of the action
      4. numbercall – Number of times this action has to be run. If we expect the action to run indefinitely, set it to -1.
      5. doall – Boolean showing whether the missed actions have to be executed in case of server restarts.
      6. model_id – Model on which we will call this action
      7. code – Code content of the action.
      8. nextcall – Next planned execution date of this action (date/time format)
    4. Example

automated-actions

 

Leave a Reply

Your email address will not be published. Required fields are marked *

Open chat
1
Hello, can we help you?