proposals/admin-app - turbine-core - Git at Google

 Work in progress

 This proposal outlines an implementation for a standard
 Turbine admin app that could easily be extended so that
 there would be a usable base for an admin app for all
 Turbine applications.

 --------------------------------------------------------------------------
 N O T E S
 --------------------------------------------------------------------------

 The Security Service manages Users, Groups Roles and Permissions
 in the system.

 The task performed by the security service include creation and removal of
 accounts, groups, roles, and permissions; assigning users roles in groups;
 assigning roles specific permissions and construction of objects
 representing these logical entities.

 Because of pluggable nature of the Services, it is possible to create
 multiple implementations of SecurityService, for example employing database
 and directory server as the data backend.

 The SecurityService delegates to the specified pluggable components.
 The pluggable components include User and UserManager implementations.
 These classes are specified in the TR.props.

 services.TurbineSecurityService.user.class
 services.TurbineSecurityService.user.manager

 Do not use user.setPassword(password), use the following method
 to add a user: TurbineSecurity.addUser(user, password)

 --------------------------------------------------------------------------
 U S E R  A D M I N  F O R M
 --------------------------------------------------------------------------

 This will be the form used to insert/update/delete user accounts
 in the Turbine application.

 Fields:

 USERNAME
 FIRST_NAME
 LAST_NAME
 EMAIL

 NOTE:

 Roles are universal, Roles are global and apply to all Groups.
 A Group is not a Group of Roles! A Group is not a Group of Users either!
 A Group is more akin to a project.

 A Role is a single set of permissions.

 Each Group will be displayed with the same set of Roles beneath
 it in a selector box. We'll use Scarab as an example here.

 In Scarab we may have the following Groups (or projects):

 Turbine, Velocity, and ECS

 We may have the following Roles:

 Admin, Developer, Tester, and Guest

 So what we would display for each Group is a list
 of the Roles in a multi-select SelectorBox. So it might look
 something like the following:

 Turbine    Velocity    ECS
 -------    --------    ---
 Admin      Admin       Admin
 Developer  Developer   Developer
 Tester     Tester      Tester
 Guest      Guest       Guest

 So you may choose to assign Jon the role of Admin for Turbine,
 and assign Jason the role of Developer in Velocity.

 You would then use the following method to have these choices
 take affect:

 TurbineSecurity.grant(Jon, Turbine, Admin)
 TurbineSecurity.grant(Jason, Velocity, Developer)

 --------------------------------------------------------------------------
 P R O J E C T / G R O U P  A D M I N  F O R M
 --------------------------------------------------------------------------

 This will be the form used to insert/update/delete projects/groups
 in the Turbine application.

 Fields:

 GROUP_NAME

 --------------------------------------------------------------------------
 R O L E  A D M I N  F O R M
 --------------------------------------------------------------------------

 This will be the form used to insert/update/delete roles in
 a project/group in a Turbine application.

 !!
 Is this form even intended because I don't see any way to save
 the association between a role and a group currently.

 Fields:

 GROUP/PROJECT ID (I thought that roles were associated with projects/groups)
 ROLE_NAME

 --------------------------------------------------------------------------
 P E R M I S S I O N   A D M I N  F O R M
 --------------------------------------------------------------------------

 This will be the form used to insert/update/delete permission in
 a Turbine application. Fedor mentioned that permissions were
 global. I'm not exactly sure how that works right now.

 Fields:

 ?

 --------------------------------------------------------------------------
 E X T E N D I N G  T H E  A D M I N  A P P
 --------------------------------------------------------------------------

 Is there any easy way to allow Torque to generate the peers used
 by the security system. This way if any changes were required to
 the user class then it would be a matter of changing the XML schema.

 Now these are special peers with convenience methods, and methods
 specific to security. But a special set of templates could probably
 be made to accomodate this.

 Just trying to think of the best way to make a security app
 resuable WRT any customizations that might want to be made
 to the user schema.

 In most cases would it simply be the user schema that
 will want to be changed?

 Is there already a recommended way to extend the existing
 classes to make a different security system and accompanying
 admin app?

 ---

 These are notes from Rafal that I will integrate

 From Rafal.Krzewski@e-point.pl Tue Jan  2 13:32:59 2001
 Date: Tue, 02 Jan 2001 20:08:45 +0100
 From: Rafal Krzewski <Rafal.Krzewski@e-point.pl>
 To: jvanzyl@periapt.com
 Subject: admin app

     [ The following text is in the "iso-8859-2" character set. ]
     [ Your display is set for the "US-ASCII" character set.  ]
     [ Some characters may be displayed incorrectly. ]

 user list has filtering control on top of the page.
 You can chose login/first name/last name, etc and the pattern
 (* will be changed into % before going into the LIKE query)

 the links on the right should be:

 'edit' or 'details' - takes you to the edit user screen
 'roles' - take you to user-group-role edit screen
 'remove' - ask for confirmation, and...

 the second screenshot shows user-group association from OW
 which would be user-group-role in Turbine.

 we need a pulldown list for selecting a group at the to.
 it should have 'global' group preselected.

 The role-permission screen should look in a similar way.

 Roles screen will be like users, it will have

 <role name> [details] [permissions] [remove]

 Groups will have

 <group name> [details] [remove]

 and permissions exactly as above...

 Oh, there should also be 'add new' buttons (or better links)
 in all list screens.
	Work in progress

	This proposal outlines an implementation for a standard
	Turbine admin app that could easily be extended so that
	there would be a usable base for an admin app for all
	Turbine applications.

	--------------------------------------------------------------------------
	N O T E S
	--------------------------------------------------------------------------

	The Security Service manages Users, Groups Roles and Permissions
	in the system.

	The task performed by the security service include creation and removal of
	accounts, groups, roles, and permissions; assigning users roles in groups;
	assigning roles specific permissions and construction of objects
	representing these logical entities.

	Because of pluggable nature of the Services, it is possible to create
	multiple implementations of SecurityService, for example employing database
	and directory server as the data backend.

	The SecurityService delegates to the specified pluggable components.
	The pluggable components include User and UserManager implementations.
	These classes are specified in the TR.props.

	services.TurbineSecurityService.user.class
	services.TurbineSecurityService.user.manager

	Do not use user.setPassword(password), use the following method
	to add a user: TurbineSecurity.addUser(user, password)

	--------------------------------------------------------------------------
	U S E R A D M I N F O R M
	--------------------------------------------------------------------------

	This will be the form used to insert/update/delete user accounts
	in the Turbine application.

	Fields:

	USERNAME
	FIRST_NAME
	LAST_NAME
	EMAIL

	NOTE:

	Roles are universal, Roles are global and apply to all Groups.
	A Group is not a Group of Roles! A Group is not a Group of Users either!
	A Group is more akin to a project.

	A Role is a single set of permissions.

	Each Group will be displayed with the same set of Roles beneath
	it in a selector box. We'll use Scarab as an example here.

	In Scarab we may have the following Groups (or projects):

	Turbine, Velocity, and ECS

	We may have the following Roles:

	Admin, Developer, Tester, and Guest

	So what we would display for each Group is a list
	of the Roles in a multi-select SelectorBox. So it might look
	something like the following:

	Turbine Velocity ECS
	------- -------- ---
	Admin Admin Admin
	Developer Developer Developer
	Tester Tester Tester
	Guest Guest Guest

	So you may choose to assign Jon the role of Admin for Turbine,
	and assign Jason the role of Developer in Velocity.

	You would then use the following method to have these choices
	take affect:

	TurbineSecurity.grant(Jon, Turbine, Admin)
	TurbineSecurity.grant(Jason, Velocity, Developer)

	--------------------------------------------------------------------------
	P R O J E C T / G R O U P A D M I N F O R M
	--------------------------------------------------------------------------

	This will be the form used to insert/update/delete projects/groups
	in the Turbine application.

	Fields:

	GROUP_NAME

	--------------------------------------------------------------------------
	R O L E A D M I N F O R M
	--------------------------------------------------------------------------

	This will be the form used to insert/update/delete roles in
	a project/group in a Turbine application.

	!!
	Is this form even intended because I don't see any way to save
	the association between a role and a group currently.

	Fields:

	GROUP/PROJECT ID (I thought that roles were associated with projects/groups)
	ROLE_NAME

	--------------------------------------------------------------------------
	P E R M I S S I O N A D M I N F O R M
	--------------------------------------------------------------------------

	This will be the form used to insert/update/delete permission in
	a Turbine application. Fedor mentioned that permissions were
	global. I'm not exactly sure how that works right now.

	Fields:

	?

	--------------------------------------------------------------------------
	E X T E N D I N G T H E A D M I N A P P
	--------------------------------------------------------------------------

	Is there any easy way to allow Torque to generate the peers used
	by the security system. This way if any changes were required to
	the user class then it would be a matter of changing the XML schema.

	Now these are special peers with convenience methods, and methods
	specific to security. But a special set of templates could probably
	be made to accomodate this.

	Just trying to think of the best way to make a security app
	resuable WRT any customizations that might want to be made
	to the user schema.

	In most cases would it simply be the user schema that
	will want to be changed?

	Is there already a recommended way to extend the existing
	classes to make a different security system and accompanying
	admin app?

	---

	These are notes from Rafal that I will integrate

	From Rafal.Krzewski@e-point.pl Tue Jan 2 13:32:59 2001
	Date: Tue, 02 Jan 2001 20:08:45 +0100
	From: Rafal Krzewski <Rafal.Krzewski@e-point.pl>
	To: jvanzyl@periapt.com
	Subject: admin app

	[ The following text is in the "iso-8859-2" character set. ]
	[ Your display is set for the "US-ASCII" character set. ]
	[ Some characters may be displayed incorrectly. ]

	user list has filtering control on top of the page.
	You can chose login/first name/last name, etc and the pattern
	(* will be changed into % before going into the LIKE query)

	the links on the right should be:

	'edit' or 'details' - takes you to the edit user screen
	'roles' - take you to user-group-role edit screen
	'remove' - ask for confirmation, and...

	the second screenshot shows user-group association from OW
	which would be user-group-role in Turbine.

	we need a pulldown list for selecting a group at the to.
	it should have 'global' group preselected.

	The role-permission screen should look in a similar way.

	Roles screen will be like users, it will have

	<role name> [details] [permissions] [remove]

	Groups will have

	<group name> [details] [remove]

	and permissions exactly as above...

	Oh, there should also be 'add new' buttons (or better links)
	in all list screens.