# Permissions Permissions can be assigned to accounts or groups. In most cases it is recommended to assign to groups since it's easier to modify the permissions of one group instead of the permissions of multiple accounts. ## Permission Permissions are: * Create (C) * Read (R) * Update/Modify (U) * Delete (D) * Permission (P) ### Create The create permission is used in order to allow an account to create something (e.g news article, task, media file etc.) ### Read The read permission is used to allow a user to read data (e.g. news article, media file etc.) ### Update/Modify The update/modify permission is used to allow a user to modify data (e.g. news article, media file etc.) ### Delete The delete permission is used to allow a user to delete data (e.g. news article, media file etc.). However deleting something doesn't always mean that the data is completely removed. In some cases it's not possible or allowed to delete data (e.g. customer data for tax purposes). In such a case delete is usually interpreted as *hide data*. ### Permission The permission permission is used to allow a user to modify or give other users permission for certain features. ## Level These permissions can be assigned on multiple levels (descending in the following order): * Unit/Organization * Application * Module * Type * Element * Component ### Unit/Organization `Karaka` supports the definition of multiple units/organizations which is especially useful for organizations with subsidiaries or business units etc. For each unit/organization permissions can be assigned to accounts. ### Application Every unit/organization can have multiple applications. One application could for example have a shop application and ticket application, another unit/organization may only have the shop application. However accounts may only need certain permissions for certain applications in certain units/organizations. Consider a business with subsidiaries where accounts in the subsidiaries should not have the same permissions as the accounts in the parent business. ### Module Different modules provide different features, by defining the modules permissions can be managed more granular. A sales person for example doesn't need access to R&D for example. ### Type Often a module provides multiple features or functionalities. The type can be used to give accounts even more specific permissions. In a organization an account may be allowed to create new invoices for customers but is not allowed to create a new customer. ### Element The element is the unique element the account has the defined permissions for. In some cases it's necessary that an account only has permissions to specific elements. In a company a customer account for example should only have access to invoices for himself and not to invoices of other customers. ### Component The component is the lowest level for permissions. This is used in order to define (if necessary) permissions for very specific components. In a company some employees may be allowed to adjust customer data but only the accounting department may be allowed to adjust the bank information of a customer. ### Example For permissions always the next higher level (recursive) is considered (inclusive) in order to check if an account has the necessary permissions. If for example an account has all permissions (CRUDP) for one unit/organization but only reading permissions (R) assigned for a certain module in that unit/organization this user will still have all the other permissions (CRUDP) for that module since the unit/organization permission definition supersedes the module permissions e.g. Account A has the following two permissions: 1. `CRUDP` for organization `Orange` 2. `R` for module `News` in the organization `Orange` Since the account has `CRUDP` for the whole organization `Orange` the account also has `CRUDP` for the `News` module. e.g. Account B has the following two permissions: 1. `C` for organization `Orange` 2. `R` for module `News` in the organization `Orange` In this case the account has `CR` permissions for the `News` module