Prérequis

• Module odooskills_helpdesk v19.0.1.7.0 (T15).
• Sécurité du modèle déjà posée (security/ir.model.access.csv) — sinon le menu s'affiche mais les records sont invisibles.
• Connaître les champs et relations du modèle (T10/T11).

2. La vue <list>

Tableau scrollable, tri, multi-sélection, exports. C'est la porte d'entrée vers les enregistrements. Pour notre modèle helpdesk.ticket :

<record id="view_helpdesk_ticket_list" model="ir.ui.view">
    <field name="name">helpdesk.ticket.list</field>
    <field name="model">helpdesk.ticket</field>
    <field name="arch" type="xml">
        <list string="Tickets"
              decoration-danger="is_overdue"
              decoration-success="state == 'done'"
              decoration-muted="state == 'done'">
            <field name="reference"/>
            <field name="name"/>
            <field name="partner_id"/>
            <field name="category_id"/>
            <field name="user_id" widget="many2one_avatar_user"/>
            <field name="tag_ids" widget="many2many_tags"
                   options="{'color_field': 'color'}"/>
            <field name="deadline"/>
            <field name="is_overdue" invisible="1"/>
            <field name="state" widget="badge"
                   decoration-info="state == 'new'"
                   decoration-warning="state == 'in_progress'"
                   decoration-success="state == 'done'"/>
        </list>
    </field>
</record>

Points notables :

• decoration-* colorise les lignes selon une expression Python — danger (rouge), warning (orange), success (vert), info, muted, primary.
• invisible="1" — on charge is_overdue dans la vue pour pouvoir l'évaluer dans decoration-danger, sans l'afficher comme colonne.
• widget="badge" affiche la selection comme pastille colorée — très lisible sur un statut.
• widget="many2one_avatar_user" montre l'avatar utilisateur — UI Odoo moderne, disponible sur tout Many2one vers res.users.

4. La vue <search>

Souvent négligée, c'est pourtant la différence entre un module jouable et un module pro. Trois briques : champs de recherche, filtres prédéfinis, groupements.

<search string="Tickets">
    <!-- Champs : ce que tape l'utilisateur dans la barre -->
    <field name="name" string="Sujet/Référence"
           filter_domain="['|', ('name', 'ilike', self),
                                ('reference', 'ilike', self)]"/>
    <field name="partner_id"/>
    <field name="category_id"/>
    <field name="tag_ids"/>

    <!-- Filtres : cases à cocher rapides -->
    <filter name="filter_mine" string="Mes tickets"
            domain="[('user_id', '=', uid)]"/>
    <filter name="filter_unassigned" string="Non assignés"
            domain="[('user_id', '=', False)]"/>
    <separator/>
    <filter name="filter_new" string="Nouveaux"
            domain="[('state', '=', 'new')]"/>
    <filter name="filter_overdue" string="En retard"
            domain="[('is_overdue', '=', True)]"/>

    <!-- Groupements -->
    <separator/>
    <filter name="group_state" string="Statut"
            context="{'group_by': 'state'}"/>
    <filter name="group_category" string="Catégorie"
            context="{'group_by': 'category_id'}"/>
    <filter name="group_user" string="Assigné à"
            context="{'group_by': 'user_id'}"/>
</search>

Trois pépites à connaître :

• filter_domain remplace le domaine auto — indispensable pour les recherches sur plusieurs champs à la fois (ici sujet OU référence). self désigne la chaîne saisie par l'utilisateur.
• uid (pas user.id !) est disponible dans les domaines des vues search — utilisateur courant, sans eval Python.
• context="{'group_by': 'champ'}" transforme un filtre en groupement — même syntaxe, effet différent. Plusieurs group_by activés s'empilent.

6. Les menus ir.ui.menu

Trois niveaux suffisent pour un module bien structuré : racine (menu principal), catégorie (fonctionnel ou configuration), entrée cliquable (liée à une action).

<menuitem id="menu_helpdesk_root"
          name="Helpdesk"
          sequence="90"
          web_icon="odooskills_helpdesk,static/description/icon.png"/>

<menuitem id="menu_helpdesk_tickets"
          name="Tickets"
          parent="menu_helpdesk_root"
          action="action_helpdesk_ticket"
          sequence="10"/>

<menuitem id="menu_helpdesk_config"
          name="Configuration"
          parent="menu_helpdesk_root"
          sequence="90"/>

<menuitem id="menu_helpdesk_categories"
          name="Catégories"
          parent="menu_helpdesk_config"
          action="action_helpdesk_ticket_category"
          sequence="10"/>

Règles d'or :

• Un menu racine sans action est juste un conteneur — l'utilisateur ne peut pas cliquer dessus.
• L'attribut web_icon accepte module_name,chemin/icon.png — obligatoire pour apparaître dans l'App Switcher.
• sequence pilote l'ordre d'affichage — 10, 20, 30… laissent de la marge pour insérer.
• Ranger la configuration sous un sous-menu "Configuration" est la convention Odoo.

Upgrade et test visuel

./odoo-bin -c config/odoo.conf -u odooskills_helpdesk -d ta_base --stop-after-init

# Puis démarre le serveur normal et va sur http://localhost:8069
# Dans l'App Switcher : le menu "Helpdesk" doit apparaître avec son icône.
# Clique "Tickets" → tu tombes sur la liste filtrée "Nouveaux" (search_default).

Voir aussi dans cette série