Group và phân quyền

Kinh nghiệm tổ chức các Group và phân quyền một cách hiệu quả

Trobz, Chien Nguyen Minh

Việc phân quyền người dùng là một điều tất yếu, được thực hiện trong tất cả dự án ERP

Odoo cung cấp cho chúng ta 3 cơ chế phân quyền, cho phép người dùng có thể quản lý hoặc bị hạn chế truy cập đến các dữ liệu doanh nghiệp lưu trong hệ thống. 3 cơ chế đó là Access Control, Record Rules Field Access.

Dù là cơ chế nào thì việc phân quyền người dùng đều được thực hiện thông qua các Nhóm người dùng (Group). Một người dùng (User) có thể thuộc về nhiều Group khác nhau. Khi chúng ta áp đặt việc phân quyền vào Group, thì những User thuộc về Group đó sẽ bị ảnh hưởng theo.

Odoo - Mẫu 1 cho ba cột

Access Control

Được quản lý trong bảng ir.model.access. Xác định rõ ràng cho từng nhóm người dùng có được truy cập vào từng bảng dữ liệu hay không

Odoo - Mẫu 2 cho ba cột

Record Rules

Được dùng để định nghĩa quyền người dùng cho từng hành động Đọc, Thêm, Sửa, Xóa trên từng dòng dữ liệu (record) dựa trên các điều kiện (Condition).
 

Odoo - Mẫu 3 cho ba cột

Field Access

Cho phép phân quyền trên từng ORM Field dựa vào thuộc tính groups.


Khó khăn gặp phải khi thực hiện phân quyền trong các dự án thực tế tại Trobz

Lý thuyết là rất rõ ràng. Nhưng khi thực chiến, team của chúng tôi gặp rất nhiều khó khăn. Đối với các công ty lớn, họ có rất nhiều công ty con, nhiều phòng ban, trong mỗi phòng ban lại có nhiều người - mỗi người thực hiện các nhiệm vụ khác nhau. Lúc này, Nhóm người dùng và Người dùng được đưa vào một ma trận (matrix) rất lớn để cân đong đo đếm, và đi đến quyết định sẽ phân người dùng nào và nhóm nào!   

Một người dùng có thể thuộc về nhiều nhóm, một nhóm cũng có thể chứa nhiều người dùng khác nhau. Nhóm có thể được kế thừa bởi nhóm khác (lúc này hệ thống phân quyền sẽ tự động được kế thừa theo). Do các mối quan hệ chằng chịt như vậy, các vấn đề bắt đầu xuất hiện.

Khi thực hiện phân quyền cho Nhóm A, các quyền đã phân cho nhóm B bị ảnh hưởng. Ví dụ như nhân viên của cả phòng Sales và phòng Purchasing đều có thể xem đầy đủ thông tin đặc tả về sản phẩm / dịch vụ mà công ty họ đang kinh doanh. Chúng ta đã thực hiện phân quyền cho phòng Purchasing, đã pass qua giai đoạn QA (kiểm tra chất lượng tính năng) ngon lành. Tiến hành thực hiện phân quyền cho phòng Sales, mỗi nhân viên Sales chỉ được xem thông tin các sản phẩm / dịch vụ mà họ phụ trách kinh doanh. Nếu không cẩn thận thì vô tình, nhân viên phòng Purchasing cũng bị chặn quyền xem thông tin tất cả sản phẩm. Lúc này, bắt buộc team QA phải tiến hành kiểm tra chất lượng nội dung phân quyền lại cho cả phòng Purchasing (và trong thực tế, sẽ phải kiểm tra cho rất nhiều những phòng ban khác mà có liên quan).

Một hệ thống phân quyền lớn, khó lường và càng ngày càng không thể bảo trì. Sau khi vận hành một thời gian, nếu khách hàng có yêu cầu điều chỉnh phân quyền cho 1 vài phòng ban hoặc người dùng riêng biệt nào đó, đó sẽ là bài toán vô cùng nan giải. Hãy tưởng tượng bạn có 100 Nhóm người dùng cuối (end-users), nếu sửa nội dung phân quyền của 1 nhóm bất kì, có thể bạn phải kiểm tra lại ít nhất 30 Nhóm người dùng cuối khác. Một rủi ro quá lớn cho Trobz, và một chi phí quá lớn cho khách hàng. Điều đó trở thành 1 rào cản cho việc hoàn thiện phần mềm ERP, rào cản cho việc ứng dụng công nghệ thông tin vào hỗ trợ cho việc quản lý và kinh doanh của các doanh nghiệp.

Vậy chúng tôi phải làm gì? tổ chức các nhóm người dùng ra sao? Giải quyết bài toán phân quyền như thế nào để không phải trằn trọc thâu đêm? Xin mời bạn xem tiếp nội dung bên dưới.

Định nghĩa về nhóm (Group)

Chỉ có một khái niệm là Nhóm, nhưng được sử dụng cho nhiều mục đích khác nhau một cách ngầm định. Nhưng bây giờ, chúng tôi phải phân loại, và định nghĩa rõ ràng về vai trò và nhiệm vụ của từng Nhóm.

Profile group

Đại diện cho End-user. Nếu chúng ta có 100 loại End-user, thì chúng ta sẽ có 100 Profile groups. Ví dụ, tương ứng với nhân viên Sales sẽ có Profile group "Sales user profile"

Access group

Mỗi phân hệ thường sẽ có 2 Access group (Manager, User). Chúng tôi sẽ phân quyền trực tiếp trên các nhóm này. Ví dụ như phân hệ Quản lý Sản phẩm thì có "Product user" và "Product manager"

Limited group

Chúng tôi sẽ chặn quyền người dùng dựa trên các nhóm loại này. Ví dụ, NV sales căn hộ A thì không xem được thông tin về căn hộ B. Chúng tôi sẽ tạo nhóm "Sales user Limited" và áp record rule cho nó.

Các nguyên tắc

  • Không phân quyền cho Profile group. Tuyệt đối không phân quyền, dù đó là cơ chế Access right, hoặc Record rule, hoặc Field access. Chúng tôi sẽ chỉ phân quyền cho các nhóm thuộc loại Access group hoặc Limited group.

  • Cấp quyền cho Access group, ngăn chặn quyền dựa vào Limited group. Đây là một nguyên tắc cực kỳ quan trọng, theo đó, chúng tôi sẽ phân quyền Access Control cho các Access group, và tạo các Record rules cho các Limited group. Nhờ vậy, việc chặn quyền xem sản phẩm / dịch vụ của nhân viên Sales, sẽ chẳng bao giờ ảnh hưởng đến việc xem sản phẩm / dịch vụ của nhân viên Purchasing.

  • Nguyên tắc kế thừa giữa các loại nhóm. Access group chỉ có thể kế thừa từ Access group khác (nhưng cần cân nhắc để tránh kế thừa chồng chéo qua lại như 1 cái mạng nhện). Limited group tuyệt đối không kế thừa từ bất cứ nhóm nào của bất kỳ loại nhóm nào. Profile group không được kế thừa Profile group khác, nhưng có thể kế thừa từ Access group và Limited group.

  • Mỗi người dùng chỉ thuộc về 1 nhóm trực tiếp là Profile group. Ở Trobz, chúng tôi khóa toàn bộ các nhóm trên màn hình phân quyền User, và thêm 1 trường mới là Profile group. Lúc này, mỗi End-user sẽ chỉ có thể thuộc trực tiếp về 1 Profile group duy nhất. End-user vẫn có thể thuộc (gián tiếp) các nhóm Access group và Limited group thông qua cơ chế kế thừa group của Odoo.

Ví dụ điển hình

Tôi lấy 1 ví dụ về nhóm End-user là Sales user. Nhóm người dùng này được quyền xem thông tin sản phẩm, tạo đơn hàng, lập hóa đơn bán hàng, và xem thông tin giao hàng. Vậy sẽ có các nhóm như sau:

Profile group: Sales userprofile.

Access group:

  • Product user: phân quyền Access control cho nhóm này được xem các thông tin sản phẩm và thuộc tính liên quan đến sản phẩm.

  • Sales user: phân quyền Access control cho nhóm này được tạo và sửa thông tin các đơn bán hàng (Sale order).

  • Sales accountant: phân quyền Access control cho nhóm này được tạo và sửa thông tin hóa đơn (Customer invoice) ở trạng thái Draft.

  • Sales Inventory user: phân quyền Access control cho nhóm này được tạo và sửa thông tin phiếu giao hàng (Delivery order) ở trạng thái Draft.

Limited group:

  • Sale user limited: tạo 1 record rule quy định trên group này, chỉ được xem các đơn bán hàng mà họ phụ trách.

Odoo • Văn bản và hình ảnh

Màn hình Sale user profile

Bạn có thể nhìn thấy các nhóm mà Sale user profile sẽ kế thừa, được khai  báo trong tab Inherited: Product user, Sale user, Sale accountant, Sales inventory user, Sale user limited.

Nhờ vậy, mà việc cấp quyền cho Access group và hạn chế quyền dựa vào Limited group đều sẽ được áp dụng vào Profile group

Odoo • Văn bản và hình ảnh

Tạo mới hoặc sửa thông tin người dùng

Với từng người dùng, chỉ cần khai báo Profile group mô tả tương ứng với chức vụ và quyền hạn của họ trong công ty.

Người dùng tương ứng, sẽ được thừa hưởng toàn bộ cơ chế cấp phát và hạn chế quyền mà chúng tôi đã áp đặt lên Profile group.

Tài liệu kham khảo

Để hiểu sâu hơn về các vấn đề liên quan tới group và phân quyền trong Odoo, các bạn có thể xem thêm các link sau:

Cảm ơn bạn đã xem blog của tôi!

Nếu bạn muốn trao đổi thêm hoặc có điểm nào chưa rõ, hãy vào Forum để chúng ta cùng trao đổi nhé.