**************************************************
	   ***  MCRUD PHASE ACCESS RULES FOR OT4OMT 4.0   ***
           **************************************************

IMPORTANT NOTICE IMPORTANT NOTICE IMPORTANT NOTICE IMPORTANT NOTICE IMPORTAN NOT

This piece of TCL will not 'correct' or 'change' the access rights on
existing Systems and Diagrams in an existing project. Applying this TCL 
in an existing project with existing Systems and files will make access
for the current users of that project very complicated. 

This TCL is meant to adopt on an EMPTY project, only with the phases
created.

!!!WARNING WARNING WARNING WARNING WARNING WARNING WARNING WARNING WARNING!!!

Please also note that this is currently unsupported and uncertified software. 

In no event shall Cadre be liable for (I) any damages caused by licensee's 
failure to perform its responsibilities or (II) any incidental, special, 
indirect, exemplary or consequential damages of licensee whatsoever, 
including but not limited to loss of programs or data, or lost profits, 
even if Cadre has been advised, knew, or should have known of the possibility 
of such damages and regardless of the form of action in which such damages 
are sought. Further more all noted Disclaimers of warranty and limitations of 
liability are in place as included in the Cadre's Software Support Agreement 
with licensee.

!!!WARNING WARNING WARNING WARNING WARNING WARNING WARNING WARNING WARNING!!!

END IMPORTANT NOTICE END IMPORTANT NOTICE END IMPORTANT NOTICE END IMPORTANT NOT

INTRODUCTION

The TCL in this directory is made to make a default setup of users, roles and 
access rights, directly related to the default setup of the four phases 
Analysis, SystemDesign, ObjectDesign and Implementation of specific OMT 
4.0 project via M C R U D rights.

PHASE SETUP

The TCL will also work for a different phase setup but the *.setup files need
to indicate the same name as the new user defined names for the redefined
phase names. Please note that the phases must be created via the Browser 
before this TCL will work.

LIMITATIONS

Also this setup ONLY works for a specified project and configuration(version),
with the (four) phases created. The project and the configuration must be 
specified by full name. Note that the full name for the configuration is 
a combination of its name and version number, e.g. Beta:1 stands for 
configuration 'Beta' version 1. The project name(s) and the configuration 
name-version(s) should be included in the projects.setup file. In this way 
the TCL will know for which explicit project(s) the (default) users, roles and 
access rights should be created. The users and the roles are created at 
Corporate level and the access Rights are defined from Phase level, and new 
objects below this level will inherit the access Rights (in the specified 
project configuration).

The creation of the users, roles and access rights goes via a schema listed 
in the following setup files:

projects.setup		: Setup of project(s) where scheme will be implemented
users.setup		: Setup of users which can be assiged to roles
roles.setup     	: Setup of rolenames, phases&type and access rights
userroles.setup 	: Setup to add a user to a role from roles.setup

Each setup file has an example content and some comment to explain the format,
see each .setup file for more explanation. Please note that the contents
and relations in the .setup file are NOT checked against consistency and that
the access.tcl script will give a fatal error if there is a syntax or 
semantical error (e.g. missing user in users.setup) in a .setup file.

The following default access schema is configured in the example .setup files:

FILE projects.setup

This file lists the projects and configurations in where the access control
should be implemented.

FILE users.setup

This file lists the set of (login) usernames which will participate in 
the access control.

FILE roles.setup

This is the default role access rights schema:

ProjectManager  | *             | M-C-R-U-D
ProjectMember   | *             | C-R-U-D
Analyst         | *             | R
Architect       | *             | R
Designer        | *             | R
Programmer      | *             | R
Analyst         | Analysis      | C-U-D
Architect       | SystemDesign  | C-U-D
Designer        | ObjectDesign  | C-U-D
Programmer      | Implementation| C-U-D
Tester          | ObjectDesign  | R
Tester          | Implementation| R
QA-Officer      | *             | R


The first column names the role name, and this role will be created. The
second column indicates the phase name pattern, * means all phases. The
last column indicates the set of access rights for that role in the
indicated phase. It is possible to repeat a role name, and to specify
additional access rights for a particulair phase.

FILE userroles.setup

This file assigns the roles to the users. If user1, user2 and user2 are 
allowed to have the role of Analyst you need to add the line:

Analyst | user1:Y, user2:N, user3:N

:Y and :N indicate if this role is the default role.
In the above example user1 has the default role Analyst set to On and 
user2&3 have the default set to Off. If the default is set to Off the 
user needs to activate the role via the Security menu option Activate Role.

Running the access.tcl script works in a OT4OMT environment (e.g. do 
a source of the /usr/ot4omt/.m4_login file in a C-shel). The following
command will interpret and store the .setup files:

	otsh -f crud.tcl

Some output will be shown, indicating what the script is doing.

Redefintion of the Access Schema is possible. You can start the access.tcl
script as follows:

	otsh -f crud.tcl -- -r

This will NOT create the users and the roles, but it will interpret the
roles.setup file, and resets the access rights for existing roles in the
specified project.

Technical TCL Information

The type of simple access rights can be changed by adopting the crud.tcl.
The array AllowedMap is a  binray bitmaps wich define the internal bitmap for 
the simplified Access Rights defined in the .setup file. See RIG Chapter 10. 
Access Control, Class Controled and Action for the mapping between the integer 
values in the bitmap and the related actions. Note that controlAction stands 
for Access Rights to have Access Control, e.g. redefined the Access Rights 
setup.

Known Proplems in Access Control in OMT 4.0/00 

Current roles reset by default role in new process (e.g. editor)
see also bug#5320 Clash default/activated role link

Assume the following role setup: user wmt, two roles Tester and ProjectManger.
ProjectManager is the default role for wmt (linkstatus defaultOn).
The ProjectManager has full access to the project (e.g. all rights are
explicitly allowed), and the Tester has all rights prohibited except the
readright. These access rights are set op Phase level and on the SystemList
as childrights.

The problem is that the role 'Tester' can start the editor, and edit & save
the diagram. This problem seems to be caused by the fact that the
default role ProjectManagr (which has full access to the project) is
activated when a new otsh is started from the brower, the M4 variables
M4_projroles__AccessTest=''; and M4_corproles__corporate=''; printed from
the editor show that these settings are empty, so the editor assumes the
default role. When the default role, assign all rights, was removed
(e.g. the wmt default role is now the selected default role) the
following error message is printed when the diagram is opened:

ERROR [112088]: There is no access rule that allows user 'wmt' to read list of l
inks to customization-file versions of version 'Develop.2' of system 'AccessTest
'.
ERROR [112088]: There is no access rule that allows user 'wmt' to read version '
Develop.2' of system 'AccessTest'.
ERROR [112088]: There is no access rule that allows user 'wmt' to read version '
Develop:1' of phase 'ObjectDesign' ('ObjectDesign').

This indicates again that the current effective roles are not passed to
the editor (child otsh process) and that the (initial) access rights in the
editor are the same as when the browser is started.

Setting the M4 variable before starting the Browser with:

        setenv M4_projroles__AccessTest Tester

Seems to be a temporary avoidance for this problem.


REACTIONS IMPROVEMENTS etc.

When you have used the CRUD access TCL please let us know your results,
expectations, etc. We are very intrested in your reaction, in order to
improve usability and userfriendness of the current the Access Control.
Please send your email reactions to alru@cadre.com