Đừng đoán field: đọc metadata thật của Odoo 18

Quy trình dùng fields_get, ir.model và ir.model.fields để xác nhận model, field và quyền truy cập trước khi tích hợp đọc hoặc ghi dữ liệu.

Vấn đề

Một integration thường hỏng trước khi gọi create hoặc write: code giả định database có model và field giống tài liệu mẫu. Nhưng registry thực tế còn phụ thuộc app đã cài, module custom, Studio và quyền của tài khoản tích hợp.

Tài liệu chính thức là bản đồ API. Metadata của chính database mới là danh sách những gì integration thực sự nhìn thấy.

Bằng chứng từ Odoo 18

Odoo 18 cho phép gọi fields_get() để đọc metadata field và dùng các meta-model ir.model, ir.model.fields để kiểm tra model cùng field trong hệ thống. [N1]

ir.model.fields cung cấp tên kỹ thuật, nhãn, kiểu, quan hệ, trạng thái base hoặc manual và các thuộc tính như required, readonly. Đây là dữ liệu cần xác nhận trước khi dựng payload. [N2]

Quyền field cũng tác động trực tiếp đến kết quả: field bị giới hạn theo group sẽ bị loại khỏi fields_get() và thao tác đọc/ghi có thể bị từ chối. Vì vậy phải inventory bằng đúng tài khoản service sẽ chạy integration, không dùng admin để “test cho qua”. [N3]

Quy trình tối thiểu trước một lệnh ghi

  1. Ghim host, database và Odoo 18.0 trong cấu hình integration.
  2. Đăng nhập bằng service user có đúng quyền vận hành dự kiến.
  3. Gọi fields_get() cho model mục tiêu và chỉ yêu cầu các thuộc tính cần thiết như string, type, required, readonly, relation.
  4. Từ chối payload nếu model hoặc field không xuất hiện; không tự sửa tên gần giống.
  5. Kiểm tra riêng record rules và dữ liệu thử trên môi trường staging trước production.

Ví dụ XML-RPC rút gọn:

fields = models.execute_kw(
    db, uid, api_key,
    "res.partner", "fields_get", [],
    {"attributes": ["string", "type", "required", "readonly", "relation"]},
)

Kết quả này nên được xem như một snapshot có thời hạn. Sau khi cài app, nâng cấp module hoặc đổi quyền service user, hãy lấy lại metadata.

Giới hạn

Metadata xác nhận cấu trúc và bề mặt truy cập, không chứng minh đầy đủ nghiệp vụ. Nó không thay thế việc kiểm tra onchange, compute, constraint, side effect, record rule hay chuỗi xử lý của module custom. Nếu một flow ghi có rủi ro cao, cần kiểm thử trên database đại diện trước khi mở production.