Phân quyền Odoo: 50 nhân sự không thêm một đồng license, nhưng phải làm đúng

Câu hỏi gần như luôn xuất hiện trong buổi tư vấn thứ hai: "Thêm nhân sự vào hệ thống có phải trả thêm tiền không?"

Với bản Odoo Community tự host, câu trả lời là không — về mặt bản quyền Odoo, không có giới hạn kiểu 5 user hay 10 user, và thêm người không phát sinh phí license.

Nhưng đó là câu trả lời cho câu hỏi sai. Câu hỏi đúng là: khi 50 người cùng vào một hệ thống kế toán, làm sao mỗi người chỉ thấy đúng phần việc của mình?

Câu trả lời ngắn

Không mất phí user không có nghĩa là không có giới hạn. Giới hạn thật đến từ hạ tầng và vận hành: máy chủ có đủ mạnh không, phân quyền có đủ chặt không, có backup và nhật ký thao tác không, có quy trình khóa tài khoản khi nhân sự nghỉ việc không.

Về kỹ thuật, phân quyền Odoo có ba tầng, và bỏ tầng nào cũng để lại lỗ hổng:

1. Menu — người dùng thấy phần nào của hệ thống. Đây là tầng trang trí, không phải bảo mật.
2. Model — được đọc, tạo, sửa, xóa loại dữ liệu nào.
3. Dòng dữ liệu — trong cùng một loại, thấy được những dòng nào.

Nguyên tắc bao trùm: ẩn menu không phải bảo mật. Chặn phải nằm ở tầng dữ liệu, để dù người dùng gõ thẳng URL hay gọi qua API thì hệ thống vẫn từ chối.

Khi nào mới thật sự phải trả phí theo user

Phân biệt cho rõ, vì đây là chỗ hay bị nhầm khi lập ngân sách:

Nếu dùng bản Community tự host, thêm 5, 20 hay 50 nhân sự không làm tăng phí license. Chi phí tăng nếu có là máy chủ, backup, bảo trì, hỗ trợ, đào tạo và tùy biến thêm. Chi tiết mô hình chi phí ở bài so sánh Community và Enterprise.

Vì sao vẫn phải tạo tài khoản riêng cho từng người

Cám dỗ lớn nhất khi không mất phí theo user lại là làm ngược: dùng chung một tài khoản ketoan cho cả phòng, cho tiện.

Đừng. Mỗi nhân sự một tài khoản riêng vì năm lý do, và cả năm đều là chuyện đã xảy ra ở đâu đó:

• Biết ai tạo, sửa, xóa chứng từ nào.
• Thu hồi quyền ngay khi nhân sự đổi vị trí hoặc nghỉ việc — dùng chung tài khoản thì phải đổi mật khẩu cho cả phòng.
• Giới hạn được dữ liệu theo vai trò.
• Truy vết khi có sai sót.
• Tránh tình trạng một người biết mật khẩu là xem được toàn bộ hệ thống.

Bộ tài khoản tối thiểu cho một doanh nghiệp có kho:

Dòng cuối quan trọng nhất và hay bị bỏ qua nhất — nói kỹ ở phần sau.

Tầng 1: Menu — và vì sao nó không phải bảo mật

Odoo cho phép gán menu vào nhóm người dùng, nên mỗi người chỉ thấy phần liên quan tới công việc: nhân viên nhập liệu thấy chứng từ được giao, thủ kho thấy nhập xuất tồn, giám đốc thấy báo cáo và dashboard.

Nhưng đây chỉ là bước đầu, và cần hiểu rõ giới hạn của nó: ẩn menu chỉ làm giao diện gọn hơn. Người dùng vẫn có thể gõ thẳng đường dẫn, hoặc gọi qua API — mà API thì Odoo Community mở hoàn toàn.

Nếu bảo mật của bạn dừng ở việc ẩn menu, bạn không có bảo mật.

⚠️ Warning: Có một cái bẫy kỹ thuật ở tầng này: khai nhóm quyền cho menu trong Odoo là cộng dồn, không phải ghi đè. Bỏ thuộc tính khai quyền ra khỏi mã nguồn không xóa quyền cũ đã ghi trong cơ sở dữ liệu — muốn gỡ phải khai tường minh dấu trừ. Hệ quả: hệ thống đã cài bản trước vẫn giữ quyền cũ, menu hiện lại cho người không nên thấy, mà nhìn mã nguồn thì tưởng đã gỡ. Chi tiết ở bài về những cái bẫy Odoo 19.

Tầng 2: Model — được làm gì với loại dữ liệu nào

Mỗi nhóm dữ liệu nghiệp vụ trong Odoo là một model: chứng từ kế toán, dòng hạch toán, đối tác, tài sản cố định, hồ sơ phân bổ 242, báo cáo.

Với mỗi model, cấp riêng bốn quyền:

Khuyến nghị thực tế: không cấp quyền xóa cho ai ngoài admin. Trong kế toán, sai thì làm bút toán điều chỉnh, không xóa. Đây vừa đúng nghiệp vụ vừa giảm rủi ro.

Tầng 3: Record rule — mỗi người chỉ thấy việc của mình

Đây là tầng quan trọng nhất khi nhiều người cùng làm trên một hệ thống, và cũng là tầng hay bị bỏ qua vì nó không hiện ra ở đâu cả cho tới lúc có sự cố.

Odoo gọi cơ chế này là record rule — bảo mật theo từng dòng dữ liệu. Gần giống khái niệm row-level security, nhưng thực thi ở tầng Odoo chứ không phải ở PostgreSQL.

Cấu hình được các chính sách kiểu:

Ba lưu ý kỹ thuật từ thực tế triển khai, cái nào cũng từng gây sự cố:

Một, luật lọc gắn với nhóm chỉ áp cho người trong nhóm. Người ngoài nhóm không bị đụng gì. Đây là cách an toàn nhất để giao hàng một tính năng phân quyền: cài lên không đổi gì cho ai, chỉ khi quản trị viên chủ động xếp người vào nhóm mới bắt đầu lọc.

Hai, chặn xem khác chặn ghi. Đặt quyền đọc mà để trống quyền ghi thì luật chỉ giấu dữ liệu, không cắt đường ghi. Với kho thì nên vậy, vì đường ghi còn chạm cả kho ảo của khách hàng và nhà cung cấp — chặn ghi theo kho là xác nhận phiếu xuất báo lỗi quyền ngay.

Ba, nhớ cho qua giá trị rỗng. Chứng từ không gắn kho hay không gắn phòng ban mà luật không có nhánh xử lý giá trị rỗng là chặn nhầm hàng loạt. Lỗi này thường chỉ lộ ra sau khi đã đưa vào chạy thật.

Bảo vệ thông tin nhạy cảm

Một số thông tin chỉ nên cho nhóm được phép xem: số dư ngân hàng, lợi nhuận và biên lợi nhuận, lương và chi phí nhân sự, số tài khoản ngân hàng, thông tin định danh cá nhân, cấu hình API và token tích hợp.

Nguyên tắc giống trên: không chỉ giấu trên màn hình, mà chặn quyền đọc ở tầng dữ liệu. Như vậy người không đủ quyền sẽ không đọc được cả trên giao diện, trong báo cáo, qua API lẫn qua công cụ tích hợp.

Tài khoản máy: AI, đồng bộ Lark, dashboard

Phần này đáng tách riêng vì nó là lỗ hổng phổ biến nhất trong các hệ thống đã triển khai: mọi thứ đều cắm bằng tài khoản admin cho nhanh.

Mỗi kết nối nên có một tài khoản kỹ thuật riêng:

Lý do không dùng admin không phải vì nghi ngờ ai, mà vì giới hạn thiệt hại khi khóa API rò rỉ. Khóa của một tài khoản chỉ-đọc bị lộ thì thiệt hại là lộ dữ liệu; khóa admin bị lộ thì thiệt hại là toàn bộ hệ thống.

Trong bộ module của chúng tôi, quyền cho AI được đóng gói thành một dòng chọn ngay trên form người dùng — chỉ đọc, hoặc tạo bút toán nháp không được ghi sổ. Chi tiết cách làm và vì sao guardrail phải đặt trong Odoo chứ không đặt ở lớp MCP: xem bài về cho AI đọc sổ kế toán.

Với luồng đồng bộ từ LarkSuite, nguyên tắc tương tự: tài khoản bot chỉ được đọc và tạo chứng từ nháp, không sửa được chứng từ đã ghi sổ — xem kiến trúc hai lớp.

Giới hạn thật khi số người dùng tăng

Không bị tính phí user không có nghĩa là mở rộng miễn phí. Khi số người tăng, các hạng mục sau bắt đầu có giá:

Khác biệt thực tế giữa 5-10 người dùng nhẹ và 50-100 người cùng lúc mở báo cáo, nhập chứng từ, tải Excel là rất lớn — cần tăng cấu hình, tối ưu PostgreSQL, cấu hình worker và giám sát.

Checklist chốt trước khi đưa vào dùng thật

Bước 1: Liệt kê vai trò

Kế toán viên, kế toán trưởng, thủ kho, bán hàng, giám đốc, admin, và các tài khoản máy.

Bước 2: Với mỗi vai trò, chốt được xem / sửa / tạo / xóa dữ liệu gì

Viết ra thành bảng. Nếu không viết được, nghĩa là chưa rõ quy trình.

Bước 3: Xác định có cần chia theo công ty, chi nhánh, phòng ban, người phụ trách không

Đây là căn cứ để thiết kế record rule. Quyết định sau khi đã chạy thì tốn gấp nhiều lần.

Bước 4: Chốt ai được ghi sổ, ai chỉ được tạo nháp

Ranh giới này quyết định chất lượng sổ sách nhiều hơn bất kỳ tính năng nào.

Bước 5: Chốt ai được xem báo cáo tài chính, công nợ, dòng tiền, số dư ngân hàng

Nhóm dữ liệu nhạy cảm phải chặn ở tầng dữ liệu, không chỉ ẩn menu.

Bước 6: Viết quy trình tạo tài khoản, đổi vai trò, khóa tài khoản khi nghỉ việc

Kèm bước thu hồi API key — đây là bước hay bị quên nhất.

Bước 7: Quy trình backup và thử khôi phục

Backup chưa từng được khôi phục thử thì chưa phải backup.

Kết luận

Bản Community tự host giúp tránh chi phí license theo người dùng. Nhưng giá trị thật không nằm ở chỗ tiết kiệm được tiền — nó nằm ở chỗ bạn được tự do cấp tài khoản cho đúng người mà không phải cân nhắc ngân sách, nên có thể thiết kế phân quyền theo nghiệp vụ thay vì theo túi tiền.

Điều kiện là thiết kế đúng ngay từ đầu: mỗi người một tài khoản, mỗi tài khoản chỉ thấy phần việc cần thiết, dữ liệu nhạy cảm chặn ở tầng hệ thống, tài khoản máy dùng quyền thấp, và có backup cùng nhật ký thao tác để kiểm soát rủi ro.

Sửa phân quyền sau khi đã chạy thật với hàng chục người và hàng nghìn chứng từ là việc rất tốn công — vì mọi thay đổi đều phải kiểm lại xem có chặn nhầm ai không.

Đặt lịch thiết kế ma trận phân quyền — mang theo sơ đồ tổ chức và danh sách nghiệp vụ, output là bảng vai trò và quyền chi tiết.

Câu hỏi thường gặp

Odoo Community có giới hạn số người dùng không?

Không. Bản Community tự host không giới hạn số tài khoản và không tính phí license theo người dùng cho Odoo. Giới hạn thực tế đến từ hạ tầng: máy chủ, cơ sở dữ liệu, backup và năng lực quản trị phân quyền khi số người tăng.

Ẩn menu trong Odoo có phải là bảo mật không?

Không. Ẩn menu chỉ làm giao diện gọn hơn; người dùng vẫn có thể gõ thẳng đường dẫn hoặc gọi qua API. Bảo mật thật phải nằm ở tầng quyền truy cập model và luật lọc theo từng dòng dữ liệu, để hệ thống từ chối bất kể người dùng đi vào bằng đường nào.

Record rule trong Odoo là gì?

Record rule là cơ chế bảo mật theo từng dòng dữ liệu — quyết định trong cùng một loại dữ liệu thì người dùng thấy được những bản ghi nào. Ví dụ nhân viên chỉ thấy chứng từ được giao, hoặc mỗi công ty con chỉ thấy dữ liệu của mình. Nó gần giống row-level security nhưng thực thi ở tầng Odoo chứ không phải PostgreSQL.

Có nên cho AI hoặc hệ thống ngoài dùng tài khoản admin không?

Không. Mỗi kết nối nên có tài khoản kỹ thuật riêng với quyền tối thiểu đủ dùng — AI mặc định chỉ đọc, bot đồng bộ chỉ được đọc và tạo nháp trên đúng những bảng cần thiết. Lý do là giới hạn thiệt hại khi khóa API bị rò rỉ, không phải vì nghi ngờ ai.

Có nên cấp quyền xóa chứng từ cho kế toán không?

Nên hạn chế tối đa, tốt nhất là không cấp cho ai ngoài admin. Trong kế toán, khi sai thì làm bút toán điều chỉnh chứ không xóa — điều này vừa đúng nghiệp vụ theo Luật Kế toán vừa giữ được dấu vết cho kiểm toán.

Làm sao ngăn nhân viên xem số dư ngân hàng và lợi nhuận?

Chặn quyền đọc ở tầng dữ liệu thay vì chỉ ẩn khỏi giao diện. Khi chặn đúng tầng, người không đủ quyền sẽ không đọc được thông tin đó trên màn hình, trong báo cáo xuất ra, qua API lẫn qua các công cụ tích hợp bên ngoài.

Đọc tiếp trong series

• Cho AI đọc sổ kế toán: hỏi tiếng Việt, ra Bảng cân đối kế toán
• Odoo 19: những cái bẫy đã dính
• Đang chạy LarkSuite, thêm Odoo có phải bỏ Lark không?
• Odoo Community hay Enterprise: bóc chi phí thật

Liên quan về bảo mật:

• Security scan khác gì security audit

Nguồn tham khảo

• Odoo Developer Documentation — Security in Odoo: https://www.odoo.com/documentation/19.0/developer/reference/backend/security.html
• Odoo Pricing — định nghĩa paying user: https://www.odoo.com/pricing
• Odoo Editions: https://www.odoo.com/page/editions
• Luật Kế toán 88/2015/QH13