cecille:sa
Differences
This shows you the differences between two versions of the page.
| Both sides previous revision Previous revision Next revision | Previous revision | ||
|
cecille:sa [2016/08/26 01:25] ca |
cecille:sa [2016/08/26 15:23] (current) ca |
||
|---|---|---|---|
| Line 8: | Line 8: | ||
| - | ==== Business ID==== | ||
| - | * In order for us to enter any data for a Company we first need to set up a new business entity. | ||
| - | * The Company name should be unique, that means you cannot create two companies with exactly the same name. | ||
| - | * Take note red Highlights are Mandatory Field you need to fill-in. | ||
| - | business_id.pptx | ||
| - | | ||
| - | ====PORTAL==== | ||
| - | |||
| - | * This is an integrated admin portal for you to manage the sites, their settings, access rights from anywhere and anytime. | ||
| - | * You also Use this to congfigure or maintain your company database of items, costumers, suppliers, brands, price,tables, accounts,receipts,payments, etc… | ||
| - | * Portal is a term, generally synonymous with gateway. | ||
| - | * Typical services offered by portal sites include a directory of Web sites, a facility to search for other sites, e-mail, stock quotes, and sometimes a community forum. | ||
| - | |||
| - | |||
| - | ====User's & Security==== | ||
| - | |||
| - | * a very fine-grained level of detail in assigning permissions. | ||
| - | * User-level security allows the database administrator to group users with similar needs into common pools. Permission can then be granted to work group instead of to individual users, easing the administration of permissions. | ||
| - | |||
| - | **The importance of User's, Roles and Permissions** | ||
| - | |||
| - | - Users are the people | ||
| - | - roles are their functions,and | ||
| - | - permissions define what authorizations those functions have. | ||
| - | |||
| - | ===ROLES=== | ||
| - | |||
| - | * This is a principle by which developers create a systems that limit access or restrict operations according to a user's constructed role within a system. This is also often called role-basedprinciple to ensure that authorized users do not gain access to privileged information. | ||
| - | |||
| - | ===TEAM=== | ||
| - | |||
| - | * After you have defined the Team, you can link the Team member to the Team and Role. By doing so, you can access to any of the transaction entry by Team. | ||
| - | |||
| - | ===LIMIT== | ||
| - | |||
| - | * The function on user Limit is activated for a particular transaction type only if you have set any limit for at least one user for one transaction type. | ||
| - | |||
| - | ===Visibility=== | ||
| - | |||
| - | * Once you set up any value for a particular context, all users not satisfying the condition will be barred from viewing any record in all lists in the system. | ||
| - | |||
| - | **<wrap em>The best practices for securing your system users, roles, and permissions are based on the following ideas:</wrap>** | ||
| - | |||
| - | Rethink your roles | ||
| - | Know the defaults | ||
| - | Evaluate your elevated permissions | ||
/srv/www/htdocs/wiki/data/attic/cecille/sa.1472174720.txt.gz · Last modified: 2016/08/26 01:25 by ca
Except where otherwise noted, content on this wiki is licensed under the following license: CC Attribution-Share Alike 4.0 International
