Security And User Roles

From UG

(Difference between revisions)

Jump to: navigation, search

Revision as of 19:22, 19 January 2010

Classified As and Parent Mantis

Classified As: (large) component
Parent Mantis: 607

Business Needs

System needs to have different levels of access. (As any system of this scale).

Business Requirements

BR Version 1.0

Each jaguar user should be of one access type. This type controls what resources (components, etc) and features user can use. For example "Basic Ops" can not access accounting module.

Types we need:

Basic Ops
Super Ops
Basic Acc
Super Acc
Management
Sales
Blank 1
Blank 2

Some of the Access Options we need (not a full list):

Ops Home (access to)
Admin Home
Acc Home
CT Rights Administration
Delete saved documents

Typical access options would be to allow to click on a button and proceed to a homepage of a component (example: Acc button on CT2 homepage). If user do not have enough rights then system could show pop-up stating that user has no access. Or we could simply hide that button.

One design option would in the form of table - see #Figure 1: UI

Please note that above Biz Reqs has been implemented.

BR Version 2.0

Managing access types should be through admin

Instead of hard coded "blank1", "blank2" user types we need ability to create/delete/edit as many as we wish through admin.

Superuser

We probably need to add hard coded "superuser level" that can do anything. This uname/password can not be editable through the systems UI. And it can not be deleted through the system.

New access options: per tab

System should be able to block access not only to buttons but tabs as well

Per form control

In the future we will need to create CT2 sub systems - limited versions of CT2 (with just limited functionality available). Example: trucker user would need to be able to create CT and edit/view of 40% of fields, only on Gen Tab. Ideally we would like to make it configurable through admin (vs making them hard coded).

Comments from Systems Analyst

Superuser requirements: how about using standard approach as in say Linux ?

How about giving admin user option to add/delete/edit at least some Access Options through UI as well? Say "pass though" all major buttons and Tabs.

Technical Specification

Summary

User Interface and Functionality

Entities and Attributes

Special Cases and Misc

Look And Feel

Figures

Figure 1: UI

Questions and RFC

Known Non Critical Bugs

Links to Archived / Old specs =

Any?

History

This doc has been created

--Alex 18:42, 19 January 2010 (UTC)

Re-design: Managing access types should be through admin; new access options: per tab, per form control

--Alex 18:39, 19 January 2010 (UTC)

mantis:
Biz Req updated? Y see #BR Version 2.0
Tech Spec updated? N

DB

@@ Line 65: / Line 65: @@
 * Superuser  requirements: how about using standard approach as in say Linux ?
-* How about giving them option to add/delete/edit at least some Access Options through UI as well? Say "pass though" all major buttons and Tabs.
+* How about giving admin user option to add/delete/edit at least some Access Options through UI as well? Say "pass though" all major buttons and Tabs.
 == Technical Specification ==