mirror of
https://github.com/Karaka-Management/User-Guide.git
synced 2026-01-11 12:28:40 +00:00
Merge changes
This commit is contained in:
parent
3e705566b3
commit
97c10b36b5
|
|
@ -0,0 +1,15 @@
|
|||
# Accounts
|
||||
|
||||
A account is used to bind information to a single person or a group of people. As a result of this a account is either a single person (user account) or an organization (organization account). Please don't confuse these organization accounts with groups or organizations, they are different!
|
||||
|
||||
## Organization Accounts
|
||||
|
||||
User accounts can be assigned to an organization account (or multiple) if so desired. This way it's possible to create a relation between user accounts and organization accounts. The organization account can manage permissions for all assigned user accounts. This way the organization account can give the assigned useres the same or less permissions than itself has. This way user accounts assigned to the organization account can have access to the same features and information as the organization account.
|
||||
|
||||
A simple example could be an organization account which has invoices and support tickets. The organization account can give user accounts the permission to read the invoices and tickets assigned to that organization. This way an accountant can get assigned the permissions to see the invoices but not the support tickets (which he not necessarily needs).
|
||||
|
||||
## Permissions
|
||||
|
||||
Accounts can be assigned to groups and thus inherit the permissions of these groups, directly get assigned permissions, or inherit the permissions assigned by organization accounts. Assigning permissions to groups and than assigning these groups to user/organization accounts is the preferred way to manage permissions.
|
||||
|
||||
The reason for this is that in case the permissions need to be changed, they only have to be changed once in the group and all assigned user/organization accounts get updated. If permissions are directly assigned to accounts and they need to be changed in the future, every single account needs to be modified instead of just one or two groups.
|
||||
|
|
@ -2,10 +2,6 @@
|
|||
|
||||
User groups are used for permission management, process flow as well internally by modules for user grouping. There should be no fear of creating too many user groups. A well structured user group management is key for maintianing permissions and efficient work flow. Don't be afraid to implement many groups for all kinds of purposes.
|
||||
|
||||
User groups can inherit permissions of other user groups. One group can inherit permissions from multiple different groups. It's only important to not create any circular inheritence structures e.g.
|
||||
|
||||
Group A inherits from group B which inherits from group C which however inherits from group A.
|
||||
|
||||
Such a group structure is possible but highly inefficent since all three groups now have the same permissions. Performance wise many groups and complex group relations hardly have any effect.
|
||||
User groups **cannot** inherit permissions of other user groups. The reason for this is that it becomes difficult to keep track of all of the inheritances and dependencies.
|
||||
|
||||
Permissions in general are following the whitelist approach. You cannot assign permissions that block users from performing or accessing sensitive data and functions, it's only possible to grant users the permissions for accessing these. It's highly recommended to only grant permissions to a group/user in a step-by-step aproach. All changes to groups and permissions for user accounts are logged and can be documented with comments as well documents through file upload.
|
||||
|
|
@ -0,0 +1,9 @@
|
|||
# Modules
|
||||
|
||||
Modules are smaller components of the application which provide additional features and functionality. Some modules only extend existing modules with new features and other modules provide completely new features. In some cases modules can depend on other modules in order to provide their own features (e.g. a news module requires the media module for uploading and displaying images).
|
||||
|
||||
Every module can be managed and configured in the administration panel. Updates and patches can be installed automatically or manually depending on the configuration. Modules just like the application itself provide localization for different languages and countries. Access permissions for accounts and/or groups can be defined per module and even per feature a module provides.
|
||||
|
||||
## Applications
|
||||
|
||||
In some cases it's even possible that applications are primarily build around one module. The ticket application for example is responsible for managing support tickets without showing any of the other installed modules compared to the backend where all modules are available. This is done in order to provide a clean and simple interface for users that primarily use this module. Another example would be the message application which primarily provides the features of the Messages module.
|
||||
1
administration/permissions.md
Normal file
1
administration/permissions.md
Normal file
|
|
@ -0,0 +1 @@
|
|||
|
||||
|
|
@ -2,14 +2,16 @@
|
|||
|
||||
## Internal
|
||||
|
||||
The application provides activity monitoring through error logging as well as activity logging.
|
||||
The application provides activity monitoring through error logging as well as audit trails.
|
||||
|
||||
### Error Logging
|
||||
|
||||
The error logging creates log entries whenever an error occures. These error logs contain specific information about what, when, where and who caused the error. These error messages indicate that something is not working as intended and require immediate attention. These errors however are not known to the development team since they are application specific; in order to inform the development team that there is an error it's possible to forward this error via a simple click of a button. This error can now get inspected and fixed. Make sure to report all errors so that they can get fixed. Errors that appear because of changes in the source code will be ignored since customer or third party code changes are not supported or allowed.
|
||||
|
||||
### Activity Logging
|
||||
### Audit Trails
|
||||
|
||||
The activity logging is used by modules in order to log user and system activities such as changes/updates to existing elements or the creation and deletion of elements. Elements in this context referes to all database data and state changes. These logs are important in order to investigate changes by certain people or to certain elements. Activity logs can be an important factor for audits as they prove that all changes can be inspected, supervised and tracked back. These log files can be used for complience reports as well as approval reports where certain activities need to be approved. While there are modules like the `Workflow` module which allow pre-approval in some cases a post-approval may be necessary and in these situations these logs can be used to generate a report which then can be approved.
|
||||
The audit trails are used by modules in order to log user and system activities such as changes/updates to existing elements or the creation and deletion of elements. Elements in this context referes to all database data and state changes. These logs are important in order to investigate changes by certain people or to certain elements. Activity logs can be an important factor for audits as they prove that all changes can be inspected, supervised and tracked back. These log files can be used for complience reports as well as approval reports where certain activities need to be approved. While there are modules like the `Workflow` module which allow pre-approval in some cases a post-approval may be necessary and in these situations these logs can be used to generate a report which then can be approved.
|
||||
|
||||
## External
|
||||
|
||||
Despite the internal monitoring features additional third party monitoring is recommended. Please make yourself familiar with tools that monitor network activities and server activities. These tools help to provide a high availability of your server and application, help with monitoring suspicious behavior and find and solve problems in a timely manner. In addition third party monitoring tools can help to optimize server and application configurations.
|
||||
|
|
|
|||
|
|
@ -4,6 +4,10 @@ Updates provide functionality improvements where patches provide security and bu
|
|||
|
||||
Updates and patches are only concerned with the application and libraries it comes with, system and application updates such as OS, database etc. have to be updated by the system administrator. It is adviced to only perform database updates once they are confirmed to work by Orange Management.
|
||||
|
||||
## Security
|
||||
|
||||
All updates and patches as signed by the provider to make sure that they cannot be tampered with. This way only authorized sources can provide updates and patches.
|
||||
|
||||
## Automatic Updates
|
||||
|
||||
Automatic updates can be activated in the application settings. In order use automatic updates either Cron or Windows Task Scheduler is required. Updates can be pulled in a custom defined interval thus allowing to perform updates at times with low application load to minimize user interuption.
|
||||
|
|
|
|||
Loading…
Reference in New Issue
Block a user