Controls

Razor permits such things as user access, roles, options, etc. to be controlled globally at the universe level and at the group level. These global settings are controlled by placing the appropriate file in the $RAZOR_UNIVERSE_DIR/Tables directory. Setting at the universe level may be overridden at the group level. Following is a description of these global controls.

Access controls

The file Access_list controls who may perform operations within the Razor tools. The format of the entries are:

<operation><who>

<operation> is any one of the operations listed in the table below and <who> is any combination of username, group name and role

• username is any valid user¹ account
• group name is any valid user group²
• role is any role defined in the file Roles

NOTE: Although UNIX platforms support the subscription of one user to multiple groups, the Access_list will validate users based on the primary group.

Operations may appear multiple times; with the <who> list being concatenated. In the definition of <who>, group name must be preceded by the plus ("+") symbol and role must be preceded by the percent ("%") symbol. The symbol "!" may be used to negate an entry. Some of the more esoteric options are explained with footnotes.

Operation	Associated functions
ADD_USER, REMOVE_USER, MODIFY_USER	Remote password administration operations
BRANCH, CHECKIN, CHECKOUT, FILE_PROPS, INTRODUCE, MERGE, MERGE_CHECKIN, NEW_FOLDER, PROMOTE, READONLY, REMOVE1, RENAME, REVERT, TERMINATE2, UNCHECKOUT, USER_SCRIPTS	File control operations
FILE_BUMP	Bumping major version number at checkin via command line
FILE_COMMANDS, ISSUE_COMMANDS, PROJECT_COMMANDS, THREAD_COMMANDS	Commands pull-down
FILE_VIEW	Browsing a file
REMOVE, THREAD_BUMP, THREAD_CREATE, THREAD_DUP, THREAD_EXTRACT, THREAD_MODIFY, THREAD_VIEW	Threads operations
PROJECT_CREATE, PROJECT_EXTRACT, PROJECT_MODIFY, PROJECT_VIEW, REMOVE	Project thread operations
ISSUE_DATABASE3, ISSUE_CREATE, ISSUE_MODIFY, ISSUE_VIEW, REMOVE	Issues operations
RAZOR_DOWN, RAZOR_LM_DOWN	Who can bring down the database server and license manager
USER_SCRIPTS	Who can create/modify/execute user-defined scripts

1 Removes a file in the context of file control, as well as threads and issues (since they are all just files to Razor) 2 Refers to terminating a branched file 3 Controls switching between databases

Definable roles

It's often easier to think and define access to things in terms of roles, rather than as a list of specific users. You can handle this in one of two different ways with Razor.

The first way is simply to have your System Administrator lay things out for you by judicious use of user groups. Then, instead of having only a comma separated list of users in the Permissions file (see "Permissions (issues only)" on page 269), you can give access to users by including a `+' in front of the user group name.

Another way is to take advantage of the Roles file. Noting this directly from the comments within the template for this file...

#
# This file defines Roles for use in the Permissions table for both
# user state transition permissions or email notification definition.
# Note that for email notification, group identifiers will be ignored
# if they are included in the role definition.
#
# The format of this file is role name (no spaces allowed in names)
# followed by one or more identifiers separated by spaces or commas.
# The identifiers may be any collection of user id, group id and
# other role id.  When referencing a group id, the group name must
# be preceded by a `+' character.  A role must be preceded by a `%'.
# When referencing other roles, the role must have been previously
# defined in the file.
#
# If the file $RAZOR_UNIVERSE_DIR/Tables/Roles exists, the defined
# roles will apply for all groups in the database.  If the file
# $RAZOR_UNIVERSE/DOMAIN_01/<group>/Tables/Roles exists, it will 
# take precedence over the $RAZOR_UNIVERSE_DIR/Tables/Roles file.
#
# EXAMPLES:
#
# "Razor Administrator/special user" role:
# The role RAZOR_ADMIN will be allowed to check-in or uncheck-out 
# files that have been checked out by any other user.  If this role 
# is not defined, only the user who performed the checkout of a file 
# may perform the check-in or uncheck-out of that file.
#RAZOR_ADMIN	tom
#
# Define a role CM whose users are mark, joel, deb and anyone in the
# cmteam Unix group:
#CM	mark, joel, deb, +cmteam
# 
# Define a role SW whose members are ivory, filmer and pedone as well
# as all members of the CM role:
#SW	ivory, filmer, pedone, %CM
#
# Define a role that has a large number of members:
#LEAD	jones, smith, brown, martin
#LEAD	phil, fred, steve, jane
#LEAD	donna, mary
#
# These lists will be concatenated as follows:
#LEAD = jones, smith, brown, martin, phil, fred, steve, jane, donna, mary
#

NOTE: A role called RAZOR_ADMIN can be defined that has `special' privileges. Users in RAZOR_ADMIN are allowed to check another person's file back in or uncheck another person's checked-out file.

Options

Each line consists of the following fields...

<option><value>

An Options file may be added to the Tables directory of a file control group and/or to the Tables directory of the database. This file can be used to gain more control over the individual tool, such as the version check-in process. The options at the group level take precedence over those defined at the database level. Options and the associated value must be tab separated

The Options file consists of lines containing option/value pairs. Currently supported options are: FileCheckIn or IssueText<n>.

FileCheckIn

The option FileCheckIn supports the following three possible values:

• AllowNoChange

This is the default state and will force check-in's to work in the same manner as in previous releases. The file will ALWAYS be checked in regardless of whether or not it has changed.

• WarnIfNoChange

Upon check-in if it is detected that the file has not changed since it was checked out, the user will be given the option to either continue or stop the check-in of the unchanged file. The user is presented with three choices:

• Continue - check in the unchanged file and proceed to the next file in the list
• Skip - do not check in the unchanged file and proceed to the next file in the list
• Halt - terminate the check-in process
• MustChange -

Check-in of unchanged files will not be allowed.

Upon completion of the check-in process through the GUI, the user will be notified if unchanged files were not checked in. The user will be given the option of viewing the list of files that were not checked-in.

The default state for the command line interface is to NOT check in unchanged files when the option FileCheckIn is set to WarnIfNoChange. The user will be prompted to enter "Yes" if the unchanged file should be checked-in.

NOTE: Unchanged files will remain in the checked-out state until the user performs an uncheck-out (or check-in, if allowed).

IssueText<n>

Options for controlling the modes of accessing the text areas on an issue form. Only one setting is valid per text area. The option IssueText supports the following three possible values:

• Writable (default)

users may enter data anywhere in the specified text area.

• Readonly

users may only view the specified text area.

• AppendOnly

users may only append data in the specified text area.

¹ Depending upon the License manager mode ("License manager" on page 38) the user names are defined via the local or Razor password file.
² Depending upon the License manager mode ("License manager" on page 38) the group names are defined via the local or Razor password file.