Hạn chế quyền truy cập vào dữ liệu¶

Quan trọng

This tutorial is an extension of the Server framework 101 tutorial. Make sure you have completed it and use the estate module you have built as a base for the exercises in this tutorial.

Cho đến nay chúng ta chủ yếu quan tâm đến việc triển khai các tính năng hữu ích. Tuy nhiên, trong hầu hết các tình huống kinh doanh bảo mật nhanh chóng trở thành mối lo ngại: hiện tại,

Bất kỳ nhân viên nào (là viết tắt của group_user) đều có thể tạo, đọc, cập nhật hoặc xóa thuộc tính, loại thuộc tính hoặc thẻ thuộc tính.
If estate_account is installed then only agents allowed to interact with invoicing can confirm sales as that's necessary to create an invoice.

Tuy nhiên:

Chúng tôi không muốn các bên thứ ba có thể truy cập trực tiếp vào tài sản.
Không phải tất cả nhân viên của chúng tôi đều có thể là đại lý bất động sản (ví dụ: nhân viên hành chính, người quản lý tài sản, ...), chúng tôi không muốn những người không phải là đại lý nhìn thấy các tài sản có sẵn.
Các đại lý bất động sản không cần hoặc không có quyền quyết định loại hoặc thẻ bất động sản nào có sẵn.
Các đại lý bất động sản có thể có tài sản độc quyền, chúng tôi không muốn một đại lý có thể quản lý tài sản độc quyền của người khác.
Tất cả các đại lý bất động sản đều có thể xác nhận việc bán bất động sản mà họ có thể quản lý, nhưng chúng tôi không muốn họ có thể xác thực hoặc đánh dấu là đã thanh toán bất kỳ hóa đơn nào trong hệ thống.

Ghi chú

Chúng tôi thực sự có thể ổn với một số hoặc hầu hết trong số này đối với một doanh nghiệp nhỏ.

Vì người dùng sẽ dễ dàng vô hiệu hóa các quy tắc bảo mật không cần thiết hơn là tạo chúng từ con số không, nên tốt hơn hết là bạn nên thận trọng và hạn chế quyền truy cập: người dùng có thể thoải mái truy cập đó nếu cần thiết hoặc thuận tiện.

Các nhóm¶

Xem thêm

Bạn có thể tìm thấy tài liệu liên quan đến chủ đề này trong the security reference.

Hướng dẫn viết mã ghi lại định dạng và vị trí của các mục dữ liệu chính.

Mục tiêu

Ở cuối phần này,

Chúng ta có thể tạo nhân viên thành đại lý bất động sản hoặc người quản lý bất động sản.
Người dùng admin là người quản lý bất động sản.
Chúng tôi có một nhân viên đại lý bất động sản mới không có quyền truy cập vào việc lập hóa đơn hoặc quản lý.

Sẽ không thực tế nếu gắn các quy tắc bảo mật cá nhân cho nhân viên bất cứ lúc nào chúng tôi cần thay đổi để nhóm liên kết các quy tắc bảo mật và người dùng. Chúng tương ứng với các vai trò có thể được giao cho nhân viên.

Đối với hầu hết các ứng dụng SoOn 1, cơ sở tốt là phải có vai trò người dùng và người quản lý (hoặc quản trị viên): người quản lý có thể thay đổi cấu hình của ứng dụng và giám sát toàn bộ quá trình sử dụng ứng dụng đó trong khi người dùng có thể làm tốt, sử dụng ứng dụng 2.

Đường cơ sở này có vẻ đủ cho chúng tôi:

Người quản lý bất động sản có thể định cấu hình hệ thống (quản lý các loại và thẻ có sẵn) cũng như giám sát mọi thuộc tính trong quy trình.
Các đại lý bất động sản có thể quản lý các tài sản do họ chăm sóc hoặc các tài sản không được bất kỳ đại lý nào chăm sóc cụ thể.

Để phù hợp với tính chất dựa trên dữ liệu của SoOn, một nhóm không gì khác hơn là một bản ghi của mô hình res.groups. Chúng thường là một phần của master data của mô-đun, được xác định trong một trong các tệp dữ liệu của mô-đun.

Ví dụ đơn giản có thể tìm thấy tại đây.

Exercise

Tạo tệp security.xml trong thư mục thích hợp và thêm nó vào tệp __manifest__.py.
Nếu chưa có, hãy thêm trường 'danh mục' vào __manifest__.py của bạn với giá trị Bất động sản/Môi giới.
Thêm bản ghi tạo nhóm có id estate_group_user, tên "Agent" và danh mục base.module_category_real_estate_brokerage.
Bên dưới đó, thêm bản ghi tạo nhóm có id estate_group_manager, tên "Manager" và danh mục base.module_category_real_estate_brokerage. Nhóm estate_group_manager cần bao hàm estate_group_user.

Ghi chú

danh mục đó đến từ đâu? Đó là một danh mục mô-đun. Ở đây, chúng tôi đã sử dụng id danh mục base.module_category_real_estate_brokerage được SoOn tự động tạo ra dựa trên danh mục được đặt trong __manifest__.py của mô-đun. Bạn cũng có thể tìm thấy ở đây danh sách danh mục mô-đun mặc định do SoOn cung cấp.

Mẹo

Vì chúng tôi đã sửa đổi tệp dữ liệu, hãy nhớ khởi động lại SoOn và cập nhật mô-đun bằng cách sử dụng -u Estate.

Nếu bạn đi tới Settings ‣ Management Users và mở người dùng admin ("Quản trị viên Mitchell"), bạn sẽ thấy một phần mới:

Đặt người dùng quản trị viên làm Người quản lý bất động sản.

Exercise

Thông qua giao diện web, tạo người dùng mới chỉ có quyền truy cập "đại lý bất động sản". Người dùng không được có bất kỳ quyền truy cập Lập hóa đơn hoặc Quản trị nào.

Sử dụng tab hoặc cửa sổ riêng để đăng nhập với người dùng mới (nhớ đặt mật khẩu), với tư cách là đại lý bất động sản, bạn chỉ nên xem ứng dụng bất động sản và có thể là ứng dụng Thảo luận (trò chuyện):

Quyền truy cập¶

Xem thêm

Bạn có thể tìm thấy tài liệu liên quan đến chủ đề này tại Quyền truy cập.

Mục tiêu

Ở cuối phần này,

Những nhân viên ít nhất không phải là đại lý bất động sản sẽ không nhìn thấy đơn đăng ký bất động sản.
Đại lý bất động sản sẽ không thể cập nhật loại hoặc thẻ thuộc tính.

Access rights were first introduced in Chương 4: Bảo Mật - Giới Thiệu Ngắn Gọn.

Quyền truy cập là một cách cung cấp cho người dùng quyền truy cập vào các mô hình thông qua nhóm: liên kết quyền truy cập vào một nhóm, sau đó tất cả người dùng trong nhóm đó sẽ có quyền truy cập.

Ví dụ: chúng tôi không muốn các đại lý bất động sản có thể sửa đổi loại tài sản nào có sẵn, vì vậy chúng tôi sẽ không liên kết quyền truy cập đó với nhóm "người dùng".

Quyền truy cập chỉ có thể cấp quyền truy cập chứ không thể xóa quyền truy cập: khi quyền truy cập được chọn, hệ thống sẽ xem xét liệu quyền truy cập bất kỳ nào được liên kết với người dùng (thông qua bất kỳ nhóm nào) có cấp quyền truy cập đó hay không.

nhóm	tạo nên	đọc	cập nhật	xóa bỏ
MỘT	X	X
B		X
C			X

Người dùng thuộc nhóm A và C sẽ có thể làm bất cứ điều gì ngoại trừ xóa đối tượng trong khi người dùng thuộc nhóm B và C sẽ có thể đọc và cập nhật đối tượng đó nhưng không thể tạo hoặc xóa đối tượng đó.

Ghi chú

Nhóm quyền truy cập có thể bị bỏ qua, điều này có nghĩa là ACL áp dụng cho mọi người dùng, đây là một phương án dự phòng hữu ích nhưng đầy rủi ro vì tùy thuộc vào ứng dụng được cài đặt, nó có thể cấp quyền truy cập ngay cả cho những người không phải là người dùng vào mô hình.
Nếu người dùng không có quyền truy cập thì họ sẽ không được cấp quyền truy cập (mặc định là từ chối).
Nếu một mục menu trỏ đến một model mà người dùng không có quyền truy cập và không có menu con nào mà người dùng có thể nhìn thấy thì menu sẽ không được hiển thị.

Exercise

Cập nhật tệp quyền truy cập thành:

Cấp quyền truy cập đầy đủ vào tất cả các đối tượng cho nhóm Người quản lý Bất động sản của bạn.
Cung cấp cho các đại lý (người sử dụng bất động sản) quyền truy cập chỉ đọc vào các loại và thẻ.
Không cho ai quyền xóa tài sản.
Kiểm tra xem người dùng tác nhân của bạn không thể thay đổi loại hoặc thẻ hay xóa thuộc tính nhưng họ có thể tạo hoặc cập nhật thuộc tính theo cách khác.

Cảnh báo

Hãy nhớ cung cấp các xid khác nhau cho các bản ghi ir.model.access của bạn nếu không chúng sẽ ghi đè lên nhau.

Vì người dùng "demo" không phải là đại lý hoặc người quản lý bất động sản nên họ thậm chí không thể xem ứng dụng bất động sản. Sử dụng tab hoặc cửa sổ riêng tư để kiểm tra điều này (người dùng "demo" có mật khẩu "demo").

Quy tắc ghi¶

Xem thêm

Bạn có thể tìm thấy tài liệu liên quan đến chủ đề này tại Quy tắc ghi.

Mục tiêu

Ở cuối phần này, các đại lý sẽ không thể nhìn thấy các thuộc tính dành riêng cho đồng nghiệp của họ; nhưng người quản lý vẫn có thể nhìn thấy mọi thứ.

Quyền truy cập có thể cấp quyền truy cập vào toàn bộ mô hình nhưng chúng tôi thường cần phải cụ thể hơn: trong khi một tác nhân có thể tương tác với các thuộc tính nói chung, chúng tôi có thể không muốn họ cập nhật hoặc thậm chí xem các thuộc tính do một trong những đồng nghiệp của họ quản lý.

Quy tắc bản ghi cung cấp độ chính xác đó: chúng có thể cấp hoặc từ chối quyền truy cập vào từng bản ghi:

<record id="rule_id" model="ir.rule">
    <field name="name">A description of the rule's role</field>
    <field name="model_id" ref="model_to_manage"/>
    <field name="perm_read" eval="False"/>
    <field name="groups" eval="[Command.link(ref('base.group_user'))]"/>
    <field name="domain_force">[
        '|', ('user_id', '=', user.id),
             ('user_id', '=', False)
    ]</field>
</record>

Tìm kiếm tên miền là cách quản lý quyền truy cập: nếu bản ghi vượt qua thì quyền truy cập sẽ được cấp, nếu không thì quyền truy cập sẽ bị từ chối.

Mẹo

Vì các quy tắc có xu hướng khá phức tạp và không được tạo hàng loạt nên chúng thường được tạo bằng XML thay vì CSV được sử dụng cho quyền truy cập.

Quy tắc trên:

Chỉ áp dụng cho các thao tác "tạo", "cập nhật" (ghi) và "xóa" (hủy liên kết): ở đây chúng tôi muốn mọi nhân viên đều có thể xem hồ sơ của người dùng khác nhưng chỉ tác giả/người được chuyển nhượng mới có thể cập nhật bản ghi.
Là không toàn cầu để chúng tôi có thể cung cấp quy tắc bổ sung cho ví dụ: các nhà quản lý.
Cho phép thao tác nếu người dùng hiện tại (user.id) được đặt (ví dụ: đã tạo hoặc được chỉ định) trên bản ghi hoặc nếu bản ghi không có người dùng nào được liên kết.

Ghi chú

Nếu không có quy tắc nào được xác định hoặc áp dụng cho một mô hình và hoạt động thì hoạt động đó được cho phép (mặc định-cho phép), điều này có thể có tác động kỳ lạ nếu quyền truy cập không được thiết lập chính xác (quá dễ dãi).

Exercise

Xác định quy tắc giới hạn các đại lý chỉ có thể xem hoặc sửa đổi các tài sản không có nhân viên bán hàng hoặc họ là nhân viên bán hàng.

Bạn có thể muốn tạo người dùng đại lý bất động sản thứ hai hoặc tạo một số thuộc tính mà nhân viên bán hàng là người quản lý hoặc một số người dùng khác.

Xác minh rằng (những) người quản lý bất động sản của bạn vẫn có thể xem tất cả tài sản. Nếu không, tai sao không? Nhớ:

Nhóm estate_group_manager cần bao hàm estate_group_user.

Ghi đè bảo mật¶

Vượt qua an ninh¶

Mục tiêu

Ở cuối phần này, các đại lý sẽ có thể xác nhận việc bán bất động sản mà không cần truy cập vào hóa đơn.

Nếu bạn cố gắng đánh dấu một bất động sản là "đã bán" là đại lý bất động sản, bạn sẽ gặp lỗi truy cập:

Điều này xảy ra vì estate_account cố gắng tạo hóa đơn trong quá trình này, nhưng việc tạo hóa đơn yêu cầu quyền quản lý tất cả hóa đơn.

Chúng tôi muốn các đại lý có thể xác nhận giao dịch mua hàng mà không cần họ có toàn quyền truy cập vào hóa đơn, điều đó có nghĩa là chúng tôi cần bỏ qua kiểm tra bảo mật thông thường của SoOn để tạo hóa đơn mặc dù người dùng hiện tại không có quyền làm như vậy .

Có hai cách chính để vượt qua các kiểm tra bảo mật hiện có trong SoOn, một cách cố ý hoặc do tác dụng phụ:

Phương thức sudo() sẽ tạo một tập bản ghi mới ở "chế độ sudo", phương thức này bỏ qua tất cả các quyền truy cập và quy tắc bản ghi (mặc dù việc kiểm tra nhóm và người dùng được mã hóa cứng vẫn có thể được áp dụng).
Việc thực hiện các truy vấn SQL thô sẽ bỏ qua quyền truy cập và ghi lại các quy tắc như một tác dụng phụ của việc bỏ qua chính ORM.

Exercise

Cập nhật estate_account để bỏ qua quyền truy cập và quy tắc khi tạo hóa đơn.

Nguy hiểm

Nói chung, bạn nên tránh sử dụng những tính năng này và chỉ sử dụng hết sức cẩn thận sau khi đã kiểm tra xem người dùng và hoạt động hiện tại có thể bỏ qua việc xác thực quyền truy cập thông thường hay không.

Các hoạt động được thực hiện trong các chế độ như vậy cũng phải dựa vào dữ liệu đầu vào của người dùng ít nhất có thể và phải xác thực dữ liệu đó ở mức tối đa có thể.

Lập trình kiểm tra bảo mật¶

Mục tiêu

Ở cuối phần này, việc tạo hóa đơn phải có khả năng phục hồi các vấn đề bảo mật bất kể những thay đổi đối với bất động sản.

Trong SoOn, quyền truy cập và quy tắc ghi chỉ được kiểm tra khi thực hiện truy cập dữ liệu qua ORM ví dụ: tạo, đọc, tìm kiếm, ghi hoặc hủy liên kết bản ghi thông qua các phương thức ORM. Các phương pháp khác không nhất thiết phải kiểm tra bất kỳ loại quyền truy cập nào.

Ở phần trước, chúng ta đã bỏ qua các quy tắc ghi khi tạo hóa đơn trong action_sold. Bất kỳ người dùng nào cũng có thể truy cập đường vòng này mà không cần kiểm tra quyền truy cập:

Thêm bản in vào action_sold trong estate_account trước khi tạo hóa đơn (vì việc tạo hóa đơn sẽ truy cập vào thuộc tính, do đó kích hoạt kiểm tra ACL), ví dụ:
```
print(" reached ".center(100, '='))
```

Bạn sẽ thấy đã đạt trong nhật ký SoOn của mình, kèm theo đó là lỗi truy cập.

Nguy hiểm

Chỉ vì bạn đã sử dụng mã Python không có nghĩa là bất kỳ quyền truy cập hoặc quy tắc nào đã hoặc sẽ được kiểm tra.

Hiện tại các quyền truy cập được ngầm kiểm tra bằng cách truy cập dữ liệu trên self cũng như gọi super() (thực hiện tương tự và cập nhật self), gây ra lỗi truy cập và hủy giao dịch "hủy tạo" hóa đơn của chúng tôi.

Tuy nhiên nếu điều này thay đổi trong tương lai hoặc chúng tôi thêm các tác dụng phụ vào phương pháp (ví dụ: báo cáo việc bán hàng cho cơ quan chính phủ) hoặc các lỗi được đưa vào bất động sản, ... điều đó có thể không xảy ra -các tác nhân để kích hoạt các hoạt động mà lẽ ra họ không có quyền truy cập.

Do đó, khi thực hiện các thao tác không phải CRUD hoặc bỏ qua ORM hoặc bảo mật một cách hợp pháp hoặc khi kích hoạt các tác dụng phụ khác, việc thực hiện kiểm tra bảo mật rõ ràng là cực kỳ quan trọng.

Kiểm tra bảo mật rõ ràng có thể được thực hiện bằng cách:

Kiểm tra xem người dùng hiện tại là ai (self.env.user) và đối sánh họ với các mô hình hoặc bản ghi cụ thể.
Kiểm tra xem người dùng hiện tại có các nhóm cụ thể được mã hóa cứng để cho phép hoặc từ chối một thao tác hay không (self.env.user.has_group).
Gọi phương thức check_access_rights(Operation) trên một tập bản ghi, điều này sẽ xác minh xem người dùng hiện tại có quyền truy cập vào chính mô hình hay không.
Gọi check_access_rule(hoạt động) trên một tập bản ghi không trống, điều này xác minh rằng người dùng hiện tại được phép thực hiện thao tác trên mọi bản ghi của tập hợp.

Cảnh báo

Kiểm tra quyền truy cập và kiểm tra quy tắc bản ghi là các hoạt động riêng biệt, nếu bạn đang kiểm tra quy tắc bản ghi, bạn thường muốn kiểm tra trước quyền truy cập.

Exercise

Trước khi tạo hóa đơn, hãy sử dụng check_access_rights và check_access_rule để đảm bảo rằng người dùng hiện tại có thể cập nhật các thuộc tính nói chung cũng như thuộc tính cụ thể mà hóa đơn dành cho.

Chạy lại tập lệnh bỏ qua, kiểm tra xem lỗi có xảy ra trước khi in không.

Bảo mật đa công ty¶

Xem thêm

Hướng dẫn về đa công ty để biết tổng quan về các cơ sở đa công ty nói chung và quy tắc bảo mật đa công ty nói riêng.

Một lần nữa, bạn có thể tìm thấy tài liệu về các quy tắc nói chung tại Quy tắc ghi.

Mục tiêu

Ở cuối phần này, các đại lý chỉ được phép truy cập vào các tài sản của đại lý (hoặc các đại lý) của họ.

Vì lý do này hay lý do khác, chúng tôi có thể cần quản lý hoạt động kinh doanh bất động sản của mình vì nhiều công ty, ví dụ: chúng ta có thể có các đại lý phần lớn tự chủ, cơ sở nhượng quyền thương mại hoặc nhiều thương hiệu (có thể từ việc mua lại các doanh nghiệp bất động sản khác) vẫn tách biệt về mặt pháp lý hoặc tài chính với nhau.

SoOn có thể được sử dụng để quản lý nhiều công ty trong cùng một hệ thống, tuy nhiên việc xử lý thực tế tùy thuộc vào từng mô-đun riêng lẻ: Bản thân SoOn cung cấp các công cụ để quản lý vấn đề thuộc các lĩnh vực phụ thuộc vào công ty và quy tắc đa công ty, đó là những gì chúng tôi' chúng ta sẽ quan tâm đến.

Chúng tôi muốn các đại lý khác nhau được "tách biệt" với nhau, với các thuộc tính thuộc về một đại lý nhất định và người dùng (dù là đại lý hay người quản lý) chỉ có thể xem các thuộc tính được liên kết với đại lý của họ.

Như trước đây, vì điều này dựa trên các bản ghi không tầm thường nên người dùng sẽ dễ dàng nới lỏng các quy tắc hơn là thắt chặt chúng, do đó, việc mặc định sử dụng một mô hình bảo mật tương đối mạnh hơn là điều hợp lý.

Quy tắc nhiều công ty chỉ đơn giản là các quy tắc ghi lại dựa trên các trường company_ids hoặc company_id:

company_ids là tất cả các công ty mà người dùng hiện tại có quyền truy cập
company_id là công ty hiện đang hoạt động (công ty mà người dùng hiện đang làm việc).

Quy tắc đa công ty sẽ thường sử dụng quy tắc cũ, tức là kiểm tra xem bản ghi có được liên kết với một công ty mà người dùng có quyền truy cập hay không:

<record model="ir.rule" id="hr_appraisal_plan_comp_rule">
    <field name="name">Appraisal Plan multi-company</field>
    <field name="model_id" ref="model_hr_appraisal_plan"/>
    <field name="domain_force">[
        '|', ('company_id', '=', False),
             ('company_id', 'in', company_ids)
    ]</field>
</record>

Nguy hiểm

Các quy tắc đa công ty thường là global, nếu không thì có nguy cơ cao là các quy tắc bổ sung sẽ cho phép bỏ qua các quy tắc đa công ty.

Exercise

Thêm trường company_id vào estate.property, trường này là bắt buộc (chúng tôi không muốn các thuộc tính không có đại lý) và phải mặc định là công ty hiện tại của người dùng hiện tại.
Thành lập một công ty mới, với một đại lý bất động sản mới trong công ty đó.
Người quản lý phải là thành viên của cả hai công ty.
Đại lý cũ chỉ nên là thành viên của công ty cũ.
Tạo một vài thuộc tính trong mỗi công ty (sử dụng bộ chọn công ty làm người quản lý hoặc sử dụng đại lý). Bỏ đặt nhân viên bán hàng mặc định để tránh kích hoạt quy tắc đó.
Tất cả các đại lý có thể thấy tất cả các công ty, điều không mong muốn là thêm quy tắc hồ sơ hạn chế hành vi này.

Cảnh báo

hãy nhớ --update mô-đun của bạn khi bạn thay đổi mô hình hoặc dữ liệu của nó

Khả năng hiển thị != bảo mật¶

Mục tiêu

Ở cuối phần này, đại lý bất động sản sẽ không thấy menu Cài đặt của ứng dụng bất động sản nhưng vẫn có thể đặt loại thuộc tính hoặc thẻ.

Các mô hình SoOn cụ thể có thể được liên kết trực tiếp với các nhóm (hoặc công ty hoặc người dùng). Điều quan trọng là phải tìm hiểu xem mối liên kết này là tính năng bảo mật hay khả năng hiển thị trước khi sử dụng nó:

Tính năng hiển thị có nghĩa là người dùng vẫn có thể truy cập vào mô hình hoặc ghi lại bằng cách khác, thông qua một phần khác của giao diện hoặc bằng cách thực hiện các thao tác từ xa bằng RPC, mọi thứ có thể không hiển thị trong giao diện web trong một số ngữ cảnh.
Tính năng bảo mật có nghĩa là người dùng không thể truy cập các bản ghi, trường hoặc thao tác.

Dưới đây là một số ví dụ:

Các nhóm trên trường mô hình (bằng Python) là một tính năng bảo mật, người dùng bên ngoài nhóm sẽ không thể truy xuất trường hoặc thậm chí biết nó tồn tại.

Ví dụ: trong hành động của máy chủ, chỉ người dùng hệ thống mới có thể xem hoặc cập nhật mã Python <https://github.com/odoo/odoo/blob/7058e338a980268df1c502b8b2860bdd8be9f727/odoo/addons/base/models/ir_actions.py#L414-L417> _.
Các nhóm trên xem phần tử (trong XML) là một tính năng hiển thị, người dùng bên ngoài nhóm sẽ không thể xem phần tử hoặc nội dung của phần tử đó trong biểu mẫu nhưng họ sẽ có thể tương tác với đối tượng (bao gồm cả trường đó).

Ví dụ: chỉ người quản lý mới có bộ lọc ngay lập tức để xem lượt rời đi của nhóm của họ.
Các nhóm trên menu và hành động là tính năng hiển thị, menu hoặc hành động sẽ không hiển thị trong giao diện nhưng điều đó không ngăn cản việc tương tác trực tiếp với đối tượng bên dưới.

Ví dụ: chỉ quản trị viên hệ thống mới có thể xem menu cài đặt elearning.

Exercise

Đại lý bất động sản không thể thêm loại hoặc thẻ thuộc tính nhưng có thể xem các tùy chọn của họ từ chế độ xem biểu mẫu Thuộc tính khi tạo nó.

Menu Cài đặt chỉ tạo thêm tiếng ồn cho giao diện của họ, khiến nó chỉ hiển thị với người quản lý.

Mặc dù không còn quyền truy cập vào menu Loại thuộc tính và Thẻ thuộc tính nữa, các đại lý vẫn có thể truy cập vào các đối tượng cơ bản vì họ vẫn có thể chọn thẻ hoặc loại để đặt trên thuộc tính của mình.

1: Ứng dụng SoOn là một nhóm các mô-đun liên quan bao trùm một lĩnh vực hoặc lĩnh vực kinh doanh, thường bao gồm một mô-đun cơ sở và một số phần mở rộng trên cơ sở đó để thêm các tính năng tùy chọn hoặc cụ thể hoặc liên kết với các lĩnh vực kinh doanh khác.
2: Đối với các ứng dụng được hầu hết hoặc mọi nhân viên sử dụng, vai trò "người dùng ứng dụng" có thể bị loại bỏ và khả năng của nó được cấp trực tiếp cho tất cả nhân viên, ví dụ: nói chung tất cả nhân viên có thể nộp chi phí hoặc nghỉ phép.