Security And User Roles

From UG

Revision as of 15:25, 1 April 2010 (edit) Alex (Talk | contribs) (→m902) ← Older edit		Revision as of 15:31, 26 October 2010 (edit) (undo) Alex (Talk | contribs) (→History) Newer edit →
Line 133:		Line 133:
	** Admin > Users (every tab - separate access option)		** Admin > Users (every tab - separate access option)
	** Admin > Client Companies (every tab - separate access option)		** Admin > Client Companies (every tab - separate access option)
		+
		+	=== 0002418: [EDI to TMS] (Client App Admin) (TMS Tab) Add TMS tab with config options ===
	== DB ==		== DB ==

---

Revision as of 15:31, 26 October 2010

Contents 1 Classified As and Parent Mantis 2 Business Needs 3 Business Requirements 3.1 BR Version 1.0 3.2 BR Version 2.0 3.2.1 Managing access types should be through admin 3.2.2 Superuser 3.2.3 New access options: per tab 3.2.4 Per form control 3.2.4.1 Super configurable option 3.3 Comments from Systems Analyst 4 Rapid Design 5 Detailed Design (Technical Specification) 5.1 Summary 5.2 User Interface 5.3 "Normal" Functionality (Use Cases) 5.4 "Abnormal" Functionality (Test Cases) 6 QA 6.1 Look And Feel 6.2 Figures 6.2.1 Figure 1: UI 7 Questions and RFC 8 Known Non Critical Bugs 9 Links to Archived / Old specs 10 History 10.1 This doc has been created 10.2 Re-design: Managing access types should be through admin; new access options: per tab, per form control 10.3 m902 10.4 0002418: [EDI to TMS] (Client App Admin) (TMS Tab) Add TMS tab with config options 11 DB

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 does 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 be to present a 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).

Super configurable option

• List as many options as possible in access table (all CT2 sections, sub sections, all tabs, all fields on CT profile)

• implement this only if feasible / possible

Comments from Systems Analyst

• Superuser requirements: please research alternatives and make a decision what to use, for example "Linux root approach".

• UI design: use usual "modal window approach" if possible

• first create #Preliminary Design / Prototype and review with me;

• create UI prototype in Paint or use any other tool/approach

--Alex 20:55, 29 January 2010 (UTC)

Rapid Design

• In some cases (component is non standard) we need to do preliminary not so detailed design before detailed final.
• This section does not have to be too detailed or too formalized. We shall not spend too much time on Prototypes - they can change many times.

Detailed Design (Technical Specification)

Summary

User Interface

"Normal" Functionality (Use Cases)

"Abnormal" Functionality (Test Cases)

• List unusual scenarios - things that users most of the time would not do but system must handle well

QA

This section is to be written by QA Engineer or QA Manager or Systems Analyst.

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: http://mantis.jaguarfreight.com/mantis/view.php?id=1690
• Biz Req updated? Y see #BR Version 2.0
• Tech Spec updated? N

m902

• 0000902: (*ph1)(User Access Admin) Add new lines to access table

• Add the following options:
  • Address book (every tab - separate access option)
  • Reports (every report category [see m1873] - separate access option)
  • Admin > Users (every tab - separate access option)
  • Admin > Client Companies (every tab - separate access option)

0002418: [EDI to TMS] (Client App Admin) (TMS Tab) Add TMS tab with config options

DB