POS Component Override Odoo 18

Retail business implementing Odoo POS discovers interface limitation crisis: cashiers needing quick single-item removal from orders but lacking delete button each order line forcing complete order cancellation restarting, store manager wanting bulk order clearing capability rush periods when customer changes mind but unable clearing cart one action requiring manual removal each item losing valuable transaction time, developer team attempting customize POS interface match business workflow but struggling understanding component override mechanism patch function usage, IT department needing add custom functionality POS screen without modifying core Odoo source code risking upgrade complications, and multi-location retailer requiring consistent custom POS features across all locations lacking systematic approach deploying interface modifications—creating cashier frustration slow transaction times poor customer experience development complexity and inability scaling customizations requiring component override understanding template extension JavaScript patching custom functionality injection and systematic POS customization supporting efficient operations user experience business requirements.

Odoo 18 POS component override enables systematic customization through OWL framework managing UI components buttons popups screens defining interface reactions, template extension using XML inheritance adding custom elements existing components without modifying source, patch function utilizing Odoo core utility overriding methods implementing new logic preserving upgrade compatibility, component architecture understanding JavaScript components linked templates specifying UI behavior user interactions, orderline customization adding delete icons individual order lines enabling single-item removal, control buttons modification injecting custom buttons POS control panel extending functionality, bulk operations implementing clear-all functionality removing multiple items single action improving efficiency, confirmation dialogs using ConfirmationDialog showing user prompts preventing accidental deletions, number buffer integration utilizing POS number buffer service simulating backspace actions clearing quantities, modular structure leveraging Odoo 18 modern JavaScript architecture enabling clean component extensions, and upgrade safety maintaining customizations separate patches ensuring core compatibility future Odoo versions—reducing development complexity through structured override approach improving cashier efficiency via intuitive deletion controls enhancing user experience custom functionality achieving operational excellence and achieving competitive advantage tailored POS interface supporting business-specific workflows customer satisfaction retail success.

Understanding POS Components

Modern JavaScript architecture:

Component Architecture:

Why Override Components:

Extending Orderline Template

Adding custom UI elements:

Template Extension Approach:

XML Template Code:

<?xml version="1.0" encoding="UTF-8"?>
<templates id="template" xml:space="preserve">
    <t t-inherit="point_of_sale.Orderline" t-inherit-mode="extension">
        <xpath expr="//div[@t-if='props.showTaxGroupLabels']" position="after">
            <t>
                <i style="margin-left: 3%;" id="clear_icon"
                   class="fa fa-times-circle"
                   t-on-click="(el) => this.clear_button_fun(el)"/>
            </t>
        </xpath>
    </t>
</templates>

Code Explanation:

• t-inherit: Inherits point_of_sale.Orderline template
• t-inherit-mode="extension": Extends template without replacing
• xpath: Locates element after which insert new content
• position="after": Adds icon after tax group labels
• t-on-click: Binds click event clear_button_fun method
• fa-times-circle: FontAwesome icon delete symbol

Patching Orderline Component

Defining custom behavior:

Component Patch Approach:

JavaScript Patch Code:

/** @odoo-module */
import { useService } from "@web/core/utils/hooks";
import { Orderline } from "@point_of_sale/app/generic_components/orderline/orderline";
import { patch } from "@web/core/utils/patch";
import { usePos } from "@point_of_sale/app/store/pos_hook";

patch(Orderline.prototype, {
    setup() {
        super.setup();
        this.pos = usePos();
        this.numberBuffer = useService("number_buffer");
    },
    
    async clear_button_fun(ev) {
        this.numberBuffer.sendKey('Backspace');
        this.numberBuffer.sendKey('Backspace');
    }
});

Code Breakdown:

Adding Clear All Button

Bulk deletion functionality:

Control Buttons Extension:

Button Template Code:

<?xml version="1.0" encoding="UTF-8"?>
<templates id="template" xml:space="preserve">
    <t t-name="pos_delete_orderline.ControlButtons"
       t-inherit="point_of_sale.ControlButtons" 
       t-inherit-mode="extension">
        <xpath expr="//OrderlineNoteButton" position="after">
           <button class="control-button btn btn-light text-bg-danger rounded-0 fw-bolder"
                   t-on-click="() => this.onClearLines()">
               <i class="fa fa-eraser"/>Clear All
           </button>
        </xpath>
   </t>
</templates>

Template Features:

• Inherits point_of_sale.ControlButtons
• Adds button after OrderlineNoteButton
• Uses danger styling (red) indicating destructive action
• Eraser icon indicates clearing function
• Binds click onClearLines() method

Clear All Functionality

Implementing bulk deletion:

Control Buttons Patch Code:

import { ConfirmationDialog } from "@web/core/confirmation_dialog/confirmation_dialog";
import { ControlButtons } from "@point_of_sale/app/screens/product_screen/control_buttons/control_buttons";
import { patch } from "@web/core/utils/patch";
import { _t } from "@web/core/l10n/translation";

patch(ControlButtons.prototype, {
    async onClearLines() {
        var order = this.pos.get_order();
        var lines = order.get_orderlines();
        
        if (lines.length) {
            this.dialog.add(ConfirmationDialog, {
                title: _t("Clear Orders?"),
                body: _t("Are you sure you want to delete all orders from the cart?"),
                confirm: () => {
                    lines.filter(line => line.get_product())
                         .forEach(line => order.removeOrderline(line));
                },
                confirmLabel: _t("Clear"),
                cancelLabel: _t("Cancel"),
            });
        } else {
            this.notification.add(_t("No Items to remove."), { type: "danger" });
        }
    }
});

Function Logic Breakdown:

Module Structure

Organizing custom code:

File Organization:

Manifest Asset Declaration:

'assets': {
    'point_of_sale.assets': [
        'pos_delete_orderline/static/src/js/orderline_patch.js',
        'pos_delete_orderline/static/src/js/control_buttons_patch.js',
    ],
},

Best Practices

Always Call super.setup() When Overriding Setup Method Maintaining Parent Component Initialization: Forgetting call super.setup() equals component not properly initialized missing parent functionality. Proper override: Always include super.setup() first line setup method before custom initialization, ensures parent component setup logic executed, prevents missing services hooks parent provides, maintains component lifecycle correctly, avoids cryptic errors missing dependencies. Example shows calling super.setup() then adding custom POS numberBuffer initialization. This pattern critical all component overrides ensuring proper inheritance.

Use Confirmation Dialogs Destructive Actions Preventing Accidental Data Loss: Implementing delete functionality without confirmation equals accidental deletions user frustration. User safety approach: Any action removing data (single line entire order) should show confirmation dialog, use ConfirmationDialog component consistent UI, provide clear title body explaining action consequences, offer Cancel option allowing users abort, use appropriate styling (danger red) visual warning destructive action. Example Clear All shows confirmation asking "Are sure want delete all orders cart?" preventing accidental cart clearing saving cashiers embarrassment recovering orders.

Provide User Feedback Actions Using Notifications Improving User Experience: Silent actions without feedback equals user uncertainty whether action succeeded. Feedback strategy: Show notifications after important actions confirming completion, use notification types appropriately (success actions danger errors), provide meaningful messages not just "Done" or "Error", handle edge cases like example showing "No Items remove" when cart already empty. Good feedback keeps users informed confident interface behaving expected improving overall user experience reducing support requests.

Test Component Overrides Thoroughly POS Flow Ensuring No Breaking Changes: Deploying untested component overrides equals potential POS failures during business hours. Testing checklist: Test all click events buttons ensure functions called correctly, verify doesn't break existing POS functionality (payment checkout etc), test edge cases (empty cart single item multiple items), check confirmation dialogs display correctly user can cancel, test multiple order scenarios ensuring clean state, verify works correctly after order completion starting new order. Thorough testing prevents production issues ensures customizations enhance rather than break POS workflow.

Conclusion

Odoo 18 POS component override enables systematic customization through OWL framework template extension patch function component architecture orderline customization control buttons modification bulk operations confirmation dialogs number buffer integration modular structure and upgrade safety. Reduce development complexity through structured override approach improving cashier efficiency via intuitive deletion controls enhancing user experience custom functionality achieving operational excellence and achieving competitive advantage tailored POS interface supporting business-specific workflows customer satisfaction retail success operational effectiveness.