|
DataMuseum.dkPresents historical artifacts from the history of: Rational R1000/400 Tapes |
This is an automatic "excavation" of a thematic subset of
See our Wiki for more about Rational R1000/400 Tapes Excavated with: AutoArchaeologist - Free & Open Source Software. |
top - metrics - downloadIndex: P T
Length: 187985 (0x2de51)
Types: TextFile
Names: »PM_D2_UPGRADE_PACKAGES_HELP«
└─⟦5f3412b64⟧ Bits:30000745 8mm tape, Rational 1000, ENVIRONMENT 12_6_5 TOOLS
└─⟦91c658230⟧ »DATA«
└─⟦f6fec0485⟧
└─⟦this⟧
@node !Commands.Cmvc_Access_Control
Package Cmvc_Access_Control provides commands for applying access control
to objects in systems, subsystems, and views. With these commands, a
project leader or subsystem owner can specify who can visit, import,
create, modify, or destroy such objects. Furthermore, these commands can
be used to restrict the use of operations from packages Cmvc,
Cmvc_Maintenance, and Cmvc_Hierarchy.
The commands in package Cmvc_Access_Control are intended for either
interactive or programmatic use. Package Operator provides operations
for defining groups for access control (see SMU, package Operator).
Finally, package Access_List provides operations for managing access
control outside of subsystems (see LM, package Access_List).
COMMANDS GROUPED BY TOPIC
The commands in package Cmvc_Access_Control fall into several functional
groups. They are listed here for your convenience.
Managing CMVC access classes: Add_Group, Display, Has_Access,
Remove_Group
Utilities for managing CMVC access classes: Check, Get_Access, Group_Name,
Initialize, Is_Consistent
Managing individual execution rights: Add_Right, Has_Right, Remove_Right
Managing tables of execution rights: Get_Rights, Set_Rights
KEY CONCEPTS FOR PACKAGE CMVC_ACCESS_CONTROL
Developing a project under CMVC enables you to partition the project into
subsystems, track changes to the objects in each subsystem, record
development history along with these changes, and maintain multiple
working and released views within each subsystem. Package Cmvc_Ac-
cess_Control provides support for another important aspect of project
management - namely, the ability to restrict access to the subsystems and
views in the project.
An essential requirement for many projects is for each development team to
have relatively restricted access to other teams' work, while having
relatively unrestricted (or even unlimited) access to its own work. For
example, the following scenarios illustrate typical access-control needs:
* Two teams (A and B) are developing two subsystems and Team A's
subsystem needs to import a spec view from Team B's subsystem. The
project manager wants to give Team A enough access to import the
desired spec view but wants to prevent Team A from being able to modify
any of the views in the imported subsystem.
* A subsystem development team consists of two developers and a subsystem
integrator, and each of these three team members works in his or her
own development path within the subsystem. The project manager wants to
allow each team member to check out, edit, and check in objects in his
or her own path, without being able to modify anything in the other
paths. Furthermore, the project manager wants the subsystem
integrator - but not the other developers - to be able to accept changes
from the developers' paths into the main path and then make releases
from that path.
The basic access-control capability defined in package Access_List is not
powerful enough to completely support scenarios such as those described
above. At best, basic access control can be used to set the access lists
(ACLs) of objects in a subsystem individually. However, managing access at
the level of individual objects is impractical and error-prone due to the
complex structure of subsystems. Improperly set ACLs within subsystems can
cause CMVC commands to fail with confusing error messages. Finally,
package Access_List has no way to restrict or permit the execution of
individual CMVC commands such as Cmvc.Accept_Changes.
In contrast, scenarios like the preceding can be implemented using the
facilities in package Cmvc_Access_Control. These facilities extend basic
access control so that access can be managed at the level of subsystems
and views. That is, CMVC access control provides an automated way of
setting the proper ACLs for the objects in a subsystem or view, both for
user-created objects (such as Ada units) and for Environment-created
objects (such as those containing CMVC information used by the
Environment). Furthermore, these ACL settings are coordinated to support
each of four kinds of access that groups can have to specific views and
subsystems. CMVC access control also provides tools for ensuring that all
of the ACLs within a subsystem or view maintain the proper settings.
Finally, package Cmvc_Access_Control provides a means of tailoring each
group's ability to apply individual CMVC commands to specific subsystems or
views.
It is important to note that CMVC access control is an extension of basic
access control and is built on basic mechanisms like ACLs, access rights,
and groups. (See package Access_List, LM, for a description of these
mechanisms.) CMVC access control thus does not replace or circumvent these
basic access-control mechanisms, but rather manages them, in much the same
way that CMVC importing manages links. Consequently, the ACL settings
provided by CMVC access control affect non-CMVC operations (such as
archiving and compilation) in addition to CMVC-specific operations.
Structures That Can Be Controlled
Applications developed under CMVC exist in a hierarchy of Environment
structures. Such applications are partitioned into subsystems, which
typically contain multiple views. In addition, subsystems may be
children of systems, as described in package Cmvc_Hierarchy.
Putting applications under CMVC access control means granting groups
various kinds of access to individual views, subsystems, and systems.
Although these structures are related hierarchically, they are independent
with respect to CMVC access-control operations. That is, granting a group
access to a subsystem does not automatically grant access to any of the
views within it. Similarly, granting a group access to a system does not
automatically grant access to the subsystems that are its children.
The next sections cover basic information about CMVC access control for
views and subsystems. CMVC access control for systems is handled
separately in "CMVC Access Control and Systems," below. In general, the
information given below about subsystems applies to systems, and the
information about views applies to system views.
Access Classes
CMVC access control supports four kinds of access that groups can have to
views and subsystems. These kinds of access - called access
classes - correspond to four general ways in which groups participate in
project development under CMVC. As such, the four access classes support a
hierarchy of roles in the development process, where higher roles have
greater levels of responsibility and authority as well as greater
numbers of permitted operations. In brief:
* The Reader access class is for groups that must be able to inspect and
execute objects in views and subsystems.
* The Client access class is for groups that must be able to import views
from other subsystems.
* The Developer access class is for groups that must be able to check in,
check out, edit, and compile objects in views and subsystems.
* The Owner access class is for groups that must have complete control
over views and subsystems, including the ability to create, destroy,
change imports, and change the access to these structures.
A group must belong to one of these access classes for each view or
subsystem to which access is required. When a group belongs to an access
class for a view or subsystem, the group is granted specific access
rights - such as read (R) or read and write (RW) access - to the individual
objects in that structure. Taken together, the access rights to the
objects in a view or subsystem limit the set of operations - both general
and CMVC-related - that the group can apply to that view or subsystem. (See
the reference entry for type Access_Class for the specific sets of access
rights granted by each access class.)
Within the general limits imposed by the assigned access rights, further
optional controls called execution rights are available for restricting
the CMVC-specific operations. Execution rights constitute explicit
permission for a group to apply individual commands from packages Cmvc,
Cmvc_Hierarchy, and Cmvc_Maintenance to a given view or subsystem. By
default, a group is granted all of the execution rights allowed by its
access class; however, it is possible to revoke one or more individual
execution rights in order to restrict the group's CMVC capability. Thus,
while every group in a given access class has the same basic Environment
access to the objects in a given view or subsystem, the ability to execute
CMVC commands can be further restricted on a group-by-group basis. (See
the reference entry for type Execution_Right for a complete list of
execution rights; for lists of execution rights granted by each access
class, see the "Reference Summary for Package Cmvc_Access_Control" at the
end of this package introduction.)
A Basic Scenario
The following scenario illustrates the relationship between groups, access
classes, and structures like views and subsystems.
Assume that two users, Fred and Mary, are developing an application that
demonstrates planetary motion, which is calculated using various
algorithms. The application is partitioned into two subsystems called Demo
and Algorithms, both of which contain spec and load views. The spec and
load views from the Demo subsystem will need to import the spec view from
the Algorithms subsystem.
The development methodology for this application makes Fred responsible
for the Demo subsystem and Mary responsible for the Algorithms subsystem.
Their responsibilities require the following capabilities:
* Each developer must be able to check out, edit, check in, and compile
units within his or her own subsystem.
* Each developer must be able to inspect objects in the other subsystem
without being able to modify them.
* Both developers must be able to make releases, spec views, paths,
subpaths, and code views in their own subsystem; they must also be able
to check the consistency of or destroy these views.
* Fred must be able to perform import operations between the two
subsystems.
To obtain these capabilities, each developer must belong to one of the
four access classes for each subsystem and view in the application. Figure
1 summarizes the access-class assignments that support the desired
capabilities. (In this and the following figures, names like Fred and Mary
are group names; recall that every username also names a correponding
group with that user as a member.)
In particular, Figure 1 shows that Fred, who needs complete control over
the Demo subsystem, belongs to the Owner class for the Demo subsystem as
well as for each of the views in that subsystem. Mary, on the other hand,
belongs to the Reader class for the Demo subsystem and each of its views.
Furthermore, Figure 1 shows that Mary, who needs complete control over the
Algorithms subsystem, belongs to the Owner access class for that subsystem
and for each of its views. Fred, in turn, belongs to the Client access
class for this subsystem and for its views, so that he can import spec
views from this subsystem without being able to modify anything in it.
(See printed documentation for figure)
Figure 1 Access-Class Assignments for Fred and Mary
As a result of these access-class assignments, specific access rights are
granted to Fred and Mary for the individual objects in these subsystems
and views. For example, because Fred has Owner access and Mary has Reader
access to Demo.Rev1_0_Spec, the access list (ACL) of each object in that
view contains the entries "Fred=>RW, Mary=>R".
In contrast, the entry "Mary=>RW" appears in the ACLs of all the objects
in Algorithms.Rev1_0_Spec, which Mary owns. Furthermore, because Fred
has Client access to this view, the ACLs of all but one object also
contain the entry "Fred=>R". The one exception is the view's State.Ref-
erencers file, which is automatically updated whenever the view is
imported. Client access gives Fred read and write access to this file
("Fred=>RW"), so that it can be updated by any import operation he
executes.
It is important to note that Fred needs both Owner access to the views in
Demo and Client access to the views in Algorithms in order to import the
latter into the former. Owner access allows Fred to add, remove, or change
the imports of Demo's spec and working views; Client access allows Fred to
name Algorithm's spec view in an import operation. In addition, because he
has Client access to Algorithm's working view, Fred will automatically
have Client access to any spec views that are subsequently made from it.
(New views that are created from existing views inherit their access-class
assignments from the existing views.) However, with respect to the working
view itself (which cannot be imported), Client access is equivalent to
Reader access.
A Developer with Restricted Access
Now assume that a junior programmer, Tom, joins Mary to develop part of
the Algorithms subsystem. Tom is to work in his own subpath, where he will
develop and test his own units. When Tom has reached his development
milestones, Mary will accept changes from his subpath into the main
integration path (Rev1_Working), which she owns. When she has tested Tom's
work along with hers, she will make releases from the Rev1_Working path
(under this development methodology, no releases will be made from Tom's
subpath). Tom's capabilities are defined as follows:
* Tom must be able to check out, edit, check in, and compile units within
his subpath.
* He must be able to inspect (but not modify) objects in the main
integration path and in the spec view of the Algorithms subsystem.
* He must not be able to make releases or other kinds of views, such as
spec views, code views, paths, and the like. Nor should he be allowed
to destroy any views, including his own.
* He must not be able to inspect or modify objects in any of the views in
the Demo subsystem.
Figure 2 shows the access-class assignments that support these
capabilities. As shown, Tom belongs to the Developer access class for his
subpath (Rev1_Tom_Working) and to the Developer access class for the
Algorithms subsystem. Furthermore, Tom belongs to the Reader access class
for the other views in Algorithms - namely, the main integration path, its
releases, and the spec view.
This combination of access-class assignments permits Tom to develop
controlled objects in his subpath, while limiting what he can do to the
subpath itself or to other views. In particular, Tom's Developer access to
both the subpath and the subsystem gives him just enough access to create,
edit, and perform CMVC operations on individual objects in his subpath.
However, to perform operations that affect the entire subpath (such as
changing its model or its import), Tom would need Owner access to the
subpath. Similarly, for operations affecting the contents of the
subsystem, such as creating or destroying views, Tom would need Owner
access to the subsystem as well.
Figure 2 shows that Tom has no access to the Demo subsystem or its views.
He is therefore unable to inspect or execute any objects in Demo. Because
of this lack of access, Tom can only perform unit-testing in his own
subpath; in particular, he cannot test his work against the entire
application. In order to do this, he would need at least Reader access to
any load or code view from Demo that is named in the application's
activity. Under the current access-class assignments, Mary and Fred are
the only ones able to execute the entire application.
Note that Fred is given no access to Tom's subpath. No direct access to
this subpath is needed, because Tom's work will always be integrated into
the working view of the main path. Furthermore, no releases or spec views
will be made from Tom's subpath, so no access classes need be set up for
such views to inherit.
(See printed documentation for figure)
Figure 2 Access-Class Assignments, Including Tom's
Further Restrictions on Specific CMVC Operations
With Developer access both to the Algorithms subsystem and to his subpath,
Tom can check out objects in his subpath, check them in, make new objects
controlled, accept changes into his subpath, and so on. In fact, Tom's
Developer access to these structures allows him to perform the complete
range of CMVC operations that apply to individual objects in the subpath,
including operations that could result in loss of development history,
such as severing objects or making them uncontrolled.
Assume that Mary has decided to enforce a restrictive development
methodology in her subsystem. Under this methodology, Tom must be
prevented from executing the Cmvc.Sever and Cmvc.Make_Uncontrolled
commands in his subpath. This is achieved by revoking Tom's execution
rights for the Cmvc.Sever and Cmvc.Make_Uncontrolled commands. Recall from
above that execution rights are a mechanism for fine-tuning CMVC
capability within a basic access class. In this case, revoking the two
execution rights fine-tunes Tom's basic Developer access to his subpath.
(Note that it would not work to simply assign Tom to a less powerful
access class such as Client for either the subsystem or his subpath,
because he still needs Developer access to perform the desired CMVC
operations in his subpath.)
Setting Up the Basic Scenario
Assume that you are the project leader and that you are responsible for
setting up the application described above with the proper CMVC access
control. Assume also that the project library for this application is the
world !Programs.Planetary_Motion, which is currently empty. Finally,
assume that, in addition to the access-class assignments illustrated in
Figure 2, you as the project leader are to belong to the Owner access
class for all of the subsystems and views.
The following steps create the Algorithms and Demo subsystems with the
desired CMVC access-class assignments. These steps illustrate that new
subsystems (and their initial working views) derive their initial
access-class assignments from the ACL of the enclosing world:
1. Review the ACL of the world !Programs.Planetary_Motion, using commands
from package Access_List. Make sure that you have complete access to
this world; for example, if you belong to a group called
Project_Leader, the ACL of this world should contain an entry like
Project_Leader=>RCOD. Furthermore, the Project_Leader group must have
RW default access to this world. For simplicity in this example, no
other groups have access to this world.
2. In the !Projects.Planetary_Motion world, use the Cmvc.Initial command
to create the Algorithms subsystem and its main working view,
Rev1_Working. Access-class assignments to each of these structures are
derived automatically as follows:
* Groups with O access to the enclosing world are assigned to the
Owner access class for the new subsystem and the working view. Thus,
your group (Project_Leader) is assigned to the Owner class for
Algorithms and Algorithms.Rev1_Working.
* Groups with R access to the enclosing world are assigned to the
Reader access class for the new subsystem and the working view. (C
and D access to the enclosing world are ignored by this operation.)
Because no one else has access to !Projects.Planetary_Motion, no
other access-class assignments have been made for Algorithms and
Algorithms.Rev1_Working.
3. Use the Cmvc_Access_Control.Add_Group command to assign groups to
access classes for the Algorithms subsystem and the
Algorithms.Rev1_Working view. You will need to enter this command once
for each of the six access-class assignments listed below:
Mary Fred Tom
Algorithms Owner Client Developer
.Rev1_Working Owner Client Reader
For example, the following instance of the Add_Group command assigns
Mary to the Owner access class for the view Algorithms.Rev1_Working
(assume the command is entered from the context
!Projects.Planetary_Motion.Algorithms):
Cmvc_Access_Control.Add_Group (The_Group => "Mary",
In_Class => Cmvc_Access_Control.Owner,
View_Or_Subsystem => "Rev1_Working");
4. In the Algorithms subsystem, create the spec view Rev1_0_Spec from
Rev1_Working. The new spec view initially has the same access-class
assignments as the view from which it was created. Since these are the
desired assignments, no further assignments are necessary.
Note that the subsystem owner Mary also has sufficient capability to
perform this step; methodologies may differ with respect to who makes
spec views and when they are made.
5. In the Algorithms subsystem, create the subpath Rev1_Tom_Working from
Rev1_Working. Again, the new view initially has the same access-class
assignments as the view from which it was created. However, at this
point, only Mary has the desired access to this subpath; Tom needs
Developer access instead of Reader access, and Fred should have no
access at all. To correct this:
a. Use the Cmvc_Access_Control.Remove_Group command to remove Fred from
the Client access class for Rev1_Tom_Working.
b. Use the Cmvc_Access_Control.Add_Group command to add Tom to the
Developer access class for Rev1_Tom_Working. This command also
automatically removes Tom from the Reader access class for this
subpath.
Note that the subsystem owner Mary also has sufficient capability to
perform this step; methodologies may differ with respect to who makes
subpaths and when they are made.
6. Restrict Tom's CMVC capability in his subpath by revoking his execution
rights to the Cmvc.Sever and Cmvc.Make_Uncontrolled commands. Use the
Cmvc_Access_Control.Remove_Right command to revoke each execution
right.
Note that execution rights are defined as a series of constants in
package Cmvc_Access_Control (see the reference entry for type
Execution_Right). In general, execution rights have the same name as
the commands to which they correspond. For example, the following
command revokes Cmvc_Access_Control.Sever, which is the execution right
that controls the Cmvc.Sever command:
Cmvc_Access_Control.Remove_Right (For_Group => "Tom",
The_Right => Cmvc_Access_Control.Sever,
View_Or_Subsystem => "Rev1_Tom_Working");
7. Use steps 2 through 4 as a guide for creating and assigning CMVC access
to the Demo subsystem, its initial working view, and its spec view. In
addition, you can set up the initial imports between the views in Demo
and the spec view in Algorithms. (Note that Fred also has sufficient
capability to set up these imports; methodologies may differ with
respect to who performs the initial imports and when they are
performed.)
8. If desired, verify that the correct access-class assignments have been
made for each view and subsystem by entering the
Cmvc_Access_Control.Display command. For example, applying this command
to the working view in Demo should yield the following display:
Access Control Group List for View
!PROJECTS.PLANETARY_MOTION.DEMO.REV1_WORKING
PROJECT_LEADER : OWNER
FRED : OWNER
MARY : READER
By default, the Display command shows only access-class assignments; by
changing the default value of the Execution_Rights parameter, you can
request that each group's execution rights be displayed as well.
Ongoing Development in the Basic Scenario
Now that the basic structures and access-class assignments are set up,
Mary and Fred have sufficient access to manage subsequent development. For
example:
* If Mary creates a new spec view from an existing spec view (or from the
working view), the new spec view inherits the access-class assignments
from the source view. Fred's Client access to the new view allows him
to import the new spec view when he needs to.
* If Mary makes design changes by adding new units to an existing spec
view, Fred's Client access to this view allows him to refresh his
imports to take advantage of the new units.
* Mary can propagate changes between Tom's subpath and the main path in
Algorithms.
* When Mary makes new releases from the main integration path in
Algorithms, each new release inherits the access-class assignments from
the working view. With Client access to these releases, Fred can
execute the application using an activity that specifies any release.
Furthermore, Fred and Mary are able to accommodate changes within their
teams by adjusting the access-class assignments and execution rights that
pertain to their respective subsystems. Such changes can be made at any
time during the course of development; they take effect immediately. For
example, if Mary discovers that Tom needs to be able to sever units after
all, she can use the Add_Right command to reinstate Tom's execution right
for that operation. From that point on, Tom will be able to execute the
Cmvc.Sever command in his subpath.
As a second example, assume that a new developer named Bob joins Fred's
team. Fred has sufficient access to create a new subpath in Demo, set up
the imports between this subpath and the Algorithms spec view, and assign
Bob to the appropriate access classes (to the Developer access class for
the subsystem and the subpath and to the Reader access class for the
remaining views). Note that only Fred and the project leader have
sufficient access to add or remove imports for the new subpath, because Bob
has Developer, not Owner, access to it.
In addition, Mary (or the project leader) must grant Bob either Reader or
Client access to the Algorithms subsystem and its views. Either kind of
access will allow him to compile his subpath against the imported spec
view. Strictly speaking, only Reader access is required; Client access is
necessary only for users who will actually perform the import operations.
However, Client access may serve as a reminder that Bob's subpath is a
client of the spec view, even if Bob himself doesn't actually perform the
operations.
Note that Mary can also change Fred's access to the Algorithms subsystem
and its views. For example, she could decide for some reason to reassign
Fred to the Reader access class for Algorithms' spec view, removing him
from the Client access class for that view. Such a change would have no
effect on existing imports; however, from this point on, Fred would be
unable to execute the commands to refresh these imports or to import a new
spec view that has the same access-class assignment.
This example illustrates an important point: because a subsystem Owner can
change an access-class assignment within his or her own subsystem, some
level of cooperation must be assumed among subsystem owners and the
project leader. The ability to change access-class assignments cannot be
taken away without also taking away the ability to make releases, spec
views, and new paths in a subsystem. Project leaders can use the
Cmvc_Access_Control.Display command to verify that groups have the correct
access to the appropriate structures.
Extending the Basic Scenario: Import Networks
Assume that the application structure presented in the basic scenario is
augmented by a new higher-level subsystem called Demo_Tests, to be
developed by a subsystem owner named Sally. As shown in Figure 3, Test has
a spec view and a working view; each of these views imports the spec view
from the Demo subsystem.
At first glance, the following access-class assignments might seem
sufficient to accommodate this change in program structure:
* Assign Sally to the Owner access class for the Demo_Tests subsystem and
for each of its views.
* Assign Sally to the Client access class for the Demo subsystem and each
of its views.
Although these access-class assignments are sufficient in a basic import
scenario (with only two subsystems), they are not enough to support import
operations in a larger network of imports, where import relationships
exist among three or more subsystems. This is because such operations
need to check for consistency and circularity throughout the entire import
network, and therefore they need access to more than just the directly
imported views. (See "Developing Applications Using Multiple Subsystems"
in the Key Concepts of this book for a discussion of circularity and
consistency in imports.)
For example, suppose Sally wants her spec and working views to import a
newly created spec view in the Demo subsystem called Rev1_1_Spec. She
enters the Cmvc.Import command, which checks to make sure she has Owner
access to the importing views and Client access to Demo.Rev1_1_Spec. In
addition, however, the import operation requires that she also have at
least Reader access to the spec view in Algorithms that is imported by
Demo.Rev1_1_Spec. Reader access to this view is required so that the
operation can verify the consistency of the entire import network.
As a second example, suppose Fred wants to change the imports of his spec
and working views. As before, the import operation he executes will check
that he has Owner access to the importing views and Client access to the
imported view in the Algorithms subsystem. In addition, he needs at least
Reader access to the views in the Demo_Tests subsystem that import his
spec view. Once again, this is because the import operation needs access
to the entire import network in order to verify its consistency.
(See printed documentation for figure)
Figure 3 Extended Scenario with Proposed Access for the Import Network
Figure 3 summarizes the access-class assignments discussed above. These
access-class assignments reflect the following rule: If you are a user
who performs import operations (as part of commands like Cmvc.Make_Path
and Cmvc.Release as well as Cmvc.Import), you need some level of access to
all views in the import network, specifically:
* Owner access to the importing view
* Client access to any directly imported views
* Reader access to any indirectly imported views (spec views that are
imported by the views you're importing)
* Reader access to the views "above" you in the import network (any spec
or load view that imports your view)
Strategy for Simplifying Access-Class Assignments
This extended scenario shows that even simple import networks can greatly
increase the number of access-class assignments in a project. A large
number of access-class assignments can mean a lot of work for subsystem
owners each time a change is made in personnel or program structure.
Furthermore, a large number of access-class assignments may not even be
possible, because at most seven groups at a time can have access of any
kind to each view or subsystem. (In fact, in the extended scenario, as
many as six groups - counting Project_Leader - already need access to some
structures.)
Rather than treating each user as a separate group, it is recommended that
one or more groups be created containing meaningful (sub)sets of project
members. Then each of these larger groups can be assigned to access
classes in place of several smaller groups. (Note that operator capa-
bility is required for creating and maintaining groups.)
For example, assume again that you are the project leader in the above
scenario and that you have operator capability. The simplest way to give
everyone the access they need is to:
1. Create a group that contains everyone working on the project. In this
example, you can create a group called Project_Members that contains
Sally, Fred, Bob, Mary, and Tom.
2. Remove everyone from the Reader and Client access classes throughout
the project.
3. Assign the Project_Members group to the Client access class for every
subsystem, every spec view, and every main working view, as shown in
Figure 4.
As a result of this strategy, everyone on the project has Client access to
all of the project's structures. With this strategy, the following
requirements are met:
* Only the subsystem owners and project leader have sufficient access to
execute commands that involve import operations.
* All users have sufficient access to compile their views against their
imports and to execute the entire application.
* No user can modify any objects outside their own subsystem;
furthermore, the junior developers Tom and Bob cannot modify objects
outside their own subpaths.
(See printed documentation for figure)
Figure 4 Simplified Access Class-Assignments for the Import Network
This simplified strategy assumes a more open development methodology in
which any user can inspect any object in the application, although each
user's ability to modify objects is restricted appropriately. The
simplified strategy also permits subsystem owners to import more views than
are called for by the application's design. For example, consider the
Demo_Tests subsystem owner (Sally), who now has Client access to views in
all subsystems, including Algorithms. With this level of access, Sally can
import a spec view from Algorithms into Demo_Tests, although such an
import is not part of the design. Some level of cooperation must be
assumed among view owners to preserve application design.
Note that none of the junior team members have enough access to perform
their own imports. For example, Bob, the junior member of the Demo
subsystem team, has Client access to views in other subsystems and so
would appear to be able to import these views into his subpath. However,
he is unable to do so because he has insufficient access to his subpath
(Developer rather than Owner). He will still have to rely on Fred or the
Project_Leader to adjust his imports.
If a more restrictive methodology is desired, a project can define smaller
groups that have access to fewer structures. In the scenario above, Bob
can be removed from Project_Members and put into a group that has Reader
or Client access to only the spec views in Algorithms. This will prevent
him from inspecting or executing the entire application, while still
allowing him to compile against his subpath's imports.
Setting Up CMVC Access Control: General Guidelines
The following general guidelines summarize the steps in the basic and
extended scenarios presented above. It is recommended that you use these
guidelines in addition to the normal steps for planning and setting up
subsystems (see "Setting Up Subsystems: A Second Look" in "Developing
Applications Using Multiple Subsystems" in the Key Concepts of this book).
1. Identify the major structures in the application. What are the expected
subsystems, paths, subpaths, spec views, and so on?
2. Identify the required access-class assignments for each development
path and subpath in each subsystem:
a. Identify the users that need access to the working, spec, and
released views in the path or subpath. List the capabilities that
each user needs for each view.
b. Based on the required capabilities, determine the access class to
which each user must belong for each view in the path. As a guide,
use the reference tables in "Minimum Access-Class Assignments" at
the end of this package introduction.
A recommended approach is for the main working view in a development
path to have all of the access-class assignments that are required
for the spec views and releases in the same path. This approach
takes advantage of the fact that new views created from existing
views inherit their access-class assignments from the existing
views. Thus, the access granted for the working view will be
inherited by any spec view, release, or configuration release made
from it. (This approach was used in the scenarios presented above.)
c. Also based on the required capabilities, determine the access class
to which each user must belong for the enclosing subsystems. As a
guide, use the reference tables in "Minimum Access-Class
Assignments" at the end of this package introduction.
A simple approach that works for most methodologies is to assign
each user to the same access class for the enclosing subsystem as
for his or her own working view (path or subpath). (This approach
was used in the scenarios presented above.)
d. Note which users, if any, should be prevented from executing
CMVC-specific commands; list the execution rights that will need to
be revoked. As a guide to the execution rights that are granted with
each access class, use the reference tables in "Execution Rights" at
the end of this package introduction.
e. For easy reference, make a chart showing access-class assignments.
3. Create groups for users with common needs. The members of each group
should be users that must belong to the same access class for a specific
view or subsystem.
Setting up groups is important for minimizing the number of groups that
have access to each structure; a maximum of seven groups can have
access to a given view or subsystem. Note that operator capability is
required for setting up groups.
4. Review the ACL of the project library (the world in which the
subsystems are to be created) to verify that it has the correct ACLs.
Groups with O access to this world will automatically be assigned to
the Owner access class for the subsystems created in it. These groups
will also be Owners of the initial working view in each of these
subsystems.
5. Use Cmvc.Initial to create the desired subsystems (and their initial
working views). Note that you need to have read access (R) to the model
world named in the command, as well as to the switch file associated
with the model world.
6. Adjust the access-class assignments for each subsystem and initial
working view.
a. Set up subsystem owners.
b. Set up teams within each subsystem (developers who need access to
the various paths and subpaths).
c. Set up users who need to import, compile against, or execute the
views from other subsystems.
7. When subpaths, additional paths, spec views, and releases are created
during development, they will inherit their access-class assignments
from the source view. Adjust these assignments as necessary during
ongoing development. (Depending on methodology, this may be the
responsibility of subsystem owners.)
Miscellaneous Topics
Initializing Existing Subsystems
In the basic scenario presented above, CMVC access control was set up for
new subsystems. It is also possible to set up CMVC access control for
subsystems that were created in earlier releases of the Environment
(earlier than D_11_1_3).
To prepare an application for CMVC access control, you first must enter the
Cmvc_Access_Control.Initialize command for each subsystem in the
application. This command causes all groups that currently have owner
access (O) to a given subsystem to be assigned to the Owner access class
for that subsystem. All groups with read access (R) are assigned to the
Reader access class. (This procedure ignores create (C) and delete (D)
access.)
Within these subsystems, you must then use the Initialize command again to
initialize each view. You can use a naming expression such as the
following to initialize all the views in a given subsystem:
Cmvc_Access_Control.Initialize
(View_Or_Subsystem => "@'c(spec_view,load_view,comb_view)");
As a result, all groups that currently have owner access (O) to each named
view are assigned to the Owner access class for that view. All groups with
read access (R) are assigned to the Reader access class. (This procedure
ignores create (C) and delete (D) access.)
If subsystems and views are not initialized, CMVC operations will continue
to operate as in releases prior to D_11_1_3.
Special Control for CDB Capability
Sites that develop applications on multiple hosts need a group that can
perform operations that affect the compatibility databases (CDBs) of
primary and secondary subsystems. In general, such groups can perform
CDB-related operations if they have Owner access to the subsystems in
question.
However, because of the sensitive nature of CDB-related operations, some
sites may want additional control over who can perform them. If your site
wants to invoke special control over CDB capability, you can create a file
called !Machine.Cdb_Capability. Groups must have write access (W) to this
file in addition to Owner access to a subsystem in order to name that sub-
system in the Cmvc_Maintenance.Make_Primary,
Cmvc_Maintenance.Make_Secondary, or Cmvc_Maintenance.Destroy_Cdb
command.
The special control over CDB capability also controls whether a group can
use the Primary and Revert_Cdb options in the Archive.Restore and
Archive.Copy commands.
Checking for Access Inconsistencies
Even when CMVC access control is in effect, it is possible for users with
Owner access to use operations from packages Access_List and
Access_List_Tools to set the ACLs of individual objects within views and
subsystems. Resetting individual ACLs can cause a group to have more or
less access than is warranted by its access class. (Insufficient access to
individual objects can cause CMVC commands to fail without diagnosing
access as the problem.)
Project leaders can run the Check command before key releases or other
milestones to ensure that individual object ACLs in a view or subsystem
are consistent with that structure's access-class assignments. The Check
command can be used merely to identify inconsistencies or to repair them
as well.
A Closer Look at Access Classes and ACLs
Assigning groups to CMVC access classes affects the ACLs of objects in
views and subsystems. Understanding how access-class assignments affect
particular objects can help you to understand why each access class
supports the capabilities that it does and why separate access is required
to views and subsystems. (See the reference entry for type Access_Class
for the specific access rights granted by each access class.)
When a group belongs to an access class for a view, an entry for that
group is inserted into the ACL of every object in the view. The objects of
interest for this discussion are the user-created objects in the view and
the view's State.Referencers file. The effect of access-class assignments
on these objects is summarized below:
* User-created objects include all Ada and text objects in the Units
directory and in any user-created directory in the view. The Reader and
Client access classes grant read access (R) to every user-created
object in a view. The Developer or Owner access classes grant read and
write access (RW) to every user-created object in a view.
Note that user-created objects are treated uniformly with respect to
access rights; CMVC access control does not support setting access
rights on an object-by-object or even a subdirectory-by-subdirectory
basis within a view.
* A view's State.Referencer file is an Environment-created object
containing state information about the view; in particular, it records
the view's clients and is updated each time the view is imported by
another view. The Client, Developer, and Owner access classes grant
read and write access (RW) to this file, which permits a group to import
the view into another view.
When a group belongs to an access class for a subsystem, an entry for that
group is inserted into the ACL of all objects in the subsystem that are
not part of any view. Objects of special interest are the CMVC database,
the compatibility database (CDB) and the Configurations directory. These
objects are common to the entire subsystem and to all the views in it.
Although these objects are not themselves part of any view, a group needs
access to them to perform operations that affect individual views. The
effect of access-class assignments on these objects is summarized below:
* A subsystem's CMVC database contains information about all the
controlled objects in each view in the subsystem. This database is
updated whenever controlled objects are checked in and out, joined,
severed, and so on. Developer or Owner access to a subsystem is
required to update the CMVC database; Reader and Client access permit a
group to use the CMVC editor to browse the controlled objects in any of
the subsystem's views.
* A subsystem's CDB collects compilation information about views that are
compiled in the subsystem. The CDB is updated whenever a new unit
specification in any view is compiled for the first time. Developer or
Owner access to a subsystem is required to update the CDB; Reader and
Client access permit only limited compilation within views (only bodies
and existing specifications can be compiled).
* A subsystem's configuration objects constitute "condensed"
representations of each view in the subsystem; they contain sufficient
information to enable views to be reconstructed from the history stored
in the CMVC database. Owner access to a subsystem is required for a
group to perform operations that delete or otherwise affect
configuration objects, such as expunging the CMVC database, destroying
views along with their corresponding configuration objects, or
rebuilding views from configuration objects.
Editor Locks, Versions, and Access Classes
Commands that change access-class assignments (such as Add_Group and
Remove_Group) change the ACLs of individual objects in views and
subsystems. Therefore, such commands are sensitive to read locks and write
locks on these individual objects. More specifically, certain kinds of
locks prevent ACLs from being changed on files or Ada units. Furthermore,
other kinds of locks allow ACLs to be changed but cause new versions to be
created in the process. For simplicity, it is recommended that you enter
commands such as Add_Group and Remove_Group only when no users are viewing
or editing any of the individual objects in the view or subsystem.
However, the following discussion may help you diagnose lock-related
errors that arise when entering these commands.
As a general rule:
* You can change access-class assignments when you or other users hold
read locks on individual text or Ada objects.
* You can change access-class assignments when you hold write locks on
individual text or Ada objects.
* You cannot change access-class assignments when other users hold write
locks on individual text or Ada objects.
Changing access-class assignments has some side effects when locks are
held on individual Ada units. Specifically, if you change an access-class
assignment while you hold a read or a write lock on an Ada unit, a new
version of that unit is created on which the new ACL is set. Furthermore,
your read or write lock will automatically transfer to the new version;
the previous version with the old ACL becomes a deleted version.
Similarly, if you change an access-class assignment while another user
holds a read lock on an Ada unit, a new version is created on which the
new ACL is set. However, the other user continues to view the previous
version, which automatically becomes a deleted version.
The existence of deleted versions occasionally causes commands to fail
unexpectedly because of the out-of-date ACLs on those versions. One
workaround is to use the Library.Expunge command to destroy deleted
versions; this method may fail if you have insufficient access to the
deleted versions or if the deleted versions themselves have read locks on
them. Another workaround is to use the Cmvc_Access_Control.Check command
to reset the ACLs of the deleted versions. You should enter this command
only when there are no read or write locks on individual objects in the
view or subsystem in question.
Configuration Objects and Access Classes
The CMVC access-class assignments for each view are recorded in the state
description directory for the configuration object corresponding to that
view. Thus, if you rebuild a view from its configuration object, the
rebuilt view will have the saved access-class assignments.
Configuration objects can be used as the source for the Cmvc.Accept_Changes
command, provided that you have Reader access to the enclosing subsystem.
However, if the view that corresponds to the named configuration object
still exists, then access to the view is checked, as if the view itself
were named in the command. (At a minimum, Reader access to the view and
Developer access to the enclosing subsystem are required to accept changes
from that view into another.)
Implications for Multiple-Host Development
Developing an application on multiple hosts involves using commands from
package Archive to save, restore, or copy subsystems and views from one
R1000 to another. These archive operations are sensitive to CMVC access
control; that is, the job identity of the archive job must have the
appropriate kind of CMVC access to complete.
The Archive.Save and Archive.Copy commands require Reader access when
saving or copying views and subsystems:
* To save or copy a view, the identity of the job or archive server must
belong to a group that has Reader access to that view.
* To save or copy a subsystem and the views in it, the identity of the
job or archive server must belong to a group that has Reader access to
the subsystem and to each of the views to be archived.
You may need to set the identity of the archive server when you initiate
these operations from another R1000. For example, assume you are copying a
view from Machine_1 to Machine_2 and you are entering the Archive.Copy
command from the destination R1000, Machine_2. Then the identity of the
archive server on Machine_1 is Network_Public, which may or may not have
access to the view you are copying. If the server has no access to the
view, a message will report an access error. (If the server has no access
to the enclosing subsystem or any enclosing world, the message will report
that the specified view is undefined.) Verify that the problem is truly an
access error by checking the spelling of the specified view name. Then
correct the access problem by using a remote password to change the
identity of the archive server to a group with at least Reader access to
the view. (See package Profile in the SJM book for information about
setting remote passwords.)
The Archive.Restore command and the restore portion of the Archive.Copy
command require Owner access to the destination subsystem or world:
* To restore a view into an existing subsystem, the identity of the job
or archive server must belong to a group that has Owner access for the
subsystem into which the view is restored.
* To restore a view into a nonexistent subsystem, or to restore a
subsystem into a world, the job or archive server must be able to
create the subsystem in the destination world. Therefore, the
job/server identity must belong to a group that has RCOD access to the
world in which the subsystem is to be created. In addition, the
job/server identity must belong to a group that has RW default access
to this world.
CMVC Access Control and Systems
The subsystems in an application (or a major portion of an application)
can be identified as such by making them children of a system. Besides
providing a way of identifying groups of related subsystems, a system also
provides an automated mechanism for tracking the latest release from each
child subsystem and building activities that reference those releases.
Operations pertaining to systems are performed with commands from package
Cmvc_Hierarchy.
Systems and the system views they contain are structures that can be put
under CMVC access control. Assume that you are the system integrator who
is responsible for adding children to and making release activities in a
system called System_1. Then you need:
* Owner access to System_1 and to each of its views
* Client access to each child subsystem and its views
Owner access to a system allows you to create new views in it and to add
children to it. Client access to a subsystem allows you to make it a child
of a system. Client access to the individual views within each child
subsystem allows you to use the Cmvc_Hierarchy.Build_Activity command to
build a release activity. Strictly speaking, you need Client access only
to the releases and spec views that will be included in the release
activity. However, the Cmvc_Hierarchy.Build_Activity command also
requires at least Reader access to all other working views (including sub-
paths) in order to examine these views for inclusion in the release
activity.
Note that you can use the Cmvc_Hierarchy.Build_Activity command to import
spec views from the child subsystems into the working system view. (This
is useful if you have test programs as well as release activities in the
working system view.) In this case, you need Client access to all imported
spec views and Reader access to the remaining views in the import network.
Using Programs to Set CMVC Access
Tools for handling CMVC access control can use structures of type
Execution_Table to specify complete sets of execution rights for groups.
Site-specific sets of execution rights can be derived from the default sets
for each access class using the constants of type Execution_Table that are
defined in this package (see the reference entry for type Execution_Table).
Overriding CMVC Access Control
Members of a special predefined group called Privileged can perform any
operation on any object regardless of access-class assignments and
execution rights. To activate this capability, a member of this group must
first execute the Operator.Enable_Privileges command, which is documented
in SMU. In the standard Environment, username Operator is a member of the
Privileged group.
REFERENCE SUMMARY FOR PACKAGE CMVC_ACCESS_CONTROL
The following sections present information about access classes and
execution rights in tabular form for easy reference.
Minimum Access-Class Assignments
The tables in this section provide a short guide to the minimum access
classes that are required for various capabilities. Designated users such
as project managers can use these tables to help them decide the access
classes to which to assign their groups.
The first table lists various things that a group may need to do to a view.
For each capability, the table lists the minimum access classes to which
the group must belong, both for the view and for the subsystem enclosing
the view. The second table lists various things that a group may need to
do to a subsystem and gives the minimum access class required for each of
these capabilities.
The capabilities listed below are supported by the specified access classes
only for groups who have the default set of execution rights. Note that
the capabilities supported by a given access class can be restricted by
selectively revoking individual execution rights for a particular group.
Table 1 Minimum Access for View-Related Capabilities
-----------------------------------------------------------
| | | |
| | |Minimum |
| |Minimum |Access |
|Desired Capability |Access |to |
| |to View |Enclosing |
| | |Subsystem |
-----------------------------------------------------------
| | | |
|Browse a view using |Reader |Reader |
|Common.Definition or Cmvc.Edit | | |
-----------------------------------------------------------
| | | |
|Execute a view, including load |Reader |Reader |
|views named in activities | | |
-----------------------------------------------------------
| | | |
|Execute operations that import one | | |
|view into another | | |
| | | |
| Access to imported view |Client |Reader |
| Access to importing view |Owner |Reader |
| Access to other views in import |Reader |Reader |
|network | | |
-----------------------------------------------------------
| | | |
|Accept changes from source view | | |
|into destination view | | |
| Access to source view |Reader |Developer |
| Access to destination view |Developer |Developer |
-----------------------------------------------------------
| | | |
|Edit uncontrolled objects in view; |Developer |Reader |
|compile bodies | | |
-----------------------------------------------------------
| | | |
|Use CMVC operations on individual |Developer |Developer |
|objects in view (check out, check | | |
|in, abandon reservation, join, | | |
|sever, revert, make controlled, | | |
|make uncontrolled) as well as | | |
|editing and unlimited compilation | | |
-----------------------------------------------------------
| | | |
|Release or make copies (e.g., |Developer |Owner |
|paths, subpaths, code views, spec | | |
|views) of view | | |
-----------------------------------------------------------
| | | |
|Change view's imports and model |Owner |Reader |
-----------------------------------------------------------
| | | |
|Change view's imports and model; |Owner |Developer |
|also use CMVC operations (like | | |
|check in and out) on view's objects| | |
-----------------------------------------------------------
| | | |
|Check consistency of a view |Owner |Owner |
-----------------------------------------------------------
| | | |
|Destroy a view |Owner |Owner |
-----------------------------------------------------------
Table 2 Minimum Access for Subsystem-Related Capabilities
|----------------------------------------------------|
| | |
| |Minimum |
|Desired Capability |Access |
| |to |
| |Subsystem |
----------------------------------------------------
| | |
|Make a subsystem a child of a system |Client |
----------------------------------------------------
| | |
|Build or destroy a configuration object |Owner |
----------------------------------------------------
| | |
|Check consistency of subsystem |Owner |
----------------------------------------------------
| | |
|Expunge subsystem's CMVC database |Owner |
----------------------------------------------------
| | |
|Destroy subsystem |Owner |
----------------------------------------------------
| | |
|Change subsystem from primary to |Owner |
|secondary or from secondary to primary | |
----------------------------------------------------
Table 3 Required Access for Changing Access_Class Assignments
--------------------------------------------
| | |
|Desired Capability|Required Access |
--------------------------------------------
| | |
|Change access to a|Owner access (O) to the |
|subsystem |enclosing world or Owner |
| |access to the subsystem |
| |itself |
--------------------------------------------
| | |
|Change access to a|Owner access to the |
|view |enclosing subsystem or |
| |Owner access to the view |
| |itself |
--------------------------------------------
Execution Rights, Listed by Command
Execution rights provide control over the primitive operations in the
commands from packages Cmvc, Cmvc_Maintenance, and Cmvc_Hierarchy. A
primitive operation is a distinct portion of a command that applies to
(references or affects) a particular view, subsystem or system. Accord-
ingly, a command has one primitive operation associated with each
parameter that names a view, subsystem, or system. For example, the
Cmvc.Accept_Changes command has two primitive operations, one that applies
to the view named by the Source parameter and one that applies to the view
named by the Destination parameter.
Execution rights, defined under type Execution_Right, are the mechanism
that permits a group to apply a particular primitive operation to a
particular view, subsystem, or system. Thus, to execute a given CMVC
command, a group must have the appropriate execution right to each struc-
ture that is affected by the command's primitive operations. For example,
a group must have the Check_In and Check_Out execution rights to a view to
perform checkin and checkout operations in that view. Similarly, if the
group is to accept changes from one view to another, it must have the
Accept_Changes_Source and Accept_Changes_Destination execution rights to
the source and destination views, respectively.
Execution rights that allow primitive operations to affect views are
called view execution rights. Similarly, execution rights that allow
primitive operations to affect subsystems or systems are called subsystem
execution rights and system execution rights, respectively.
The following tables list the view, subsystem, and/or system execution
rights that are checked for each command in packages Cmvc,
Cmvc_Maintenance, and Cmvc_Hierarchy. When a command has multiple
primitive operations corresponding to multiple parameters, the table lists
one execution right for each such parameter.
Table 4 Required Execution Rights for Commands in Package Cmvc
----------------------------------------------------------
| | | |
|Command |Parameters |Required Execution Right |
----------------------------------------------------------
| | | |
|Abandon_ |What_Object |Abandon_Reservation for |
|Reservation | |view |
----------------------------------------------------------
| | | |
|Accept_Changes |Destination |Accept_Changes_ |
| |Source |Destination for view |
| | |Accept_Changes_Source for|
| | |view |
----------------------------------------------------------
| | | |
|Append_Notes |What_Object |Modify_Notes for view |
----------------------------------------------------------
| | | |
|Build |View_To_ |Import_From for views |
| |Import |Build for enclosing |
| | |subsystem |
----------------------------------------------------------
| | | |
|Check_In |What_Object |Check_In for view |
----------------------------------------------------------
| | | |
|Check_Out |What_Object |Check_Out for view |
----------------------------------------------------------
| | | |
|Compare |Destination |Query_View for view |
| |Source |Query_View for view |
----------------------------------------------------------
| | | |
|Copy |From_View |Copy for source view |
| |View_To_ |Import_From for imported |
| |Import |view |
| |View_To_ |Import_Into for importing|
| |Modify |view |
----------------------------------------------------------
| | | |
|Create_Empty_Note_|What_Object |(No rights are required) |
|Window | | |
----------------------------------------------------------
| | | |
|Def |What_Object |Query_View for view |
----------------------------------------------------------
| | | |
|Destroy_Subsystem |What_ |Destroy_Subsystem for |
| |Subsystem |subsystem |
----------------------------------------------------------
| | | |
|Destroy_System |What_ |Destroy_Subsystem for |
| |Subsystem |system |
----------------------------------------------------------
| | | |
|Destroy_View |What_View |Destroy_View for view |
| | |Destroy_Config for |
| | |enclosing subsystem |
----------------------------------------------------------
| | | |
|Edit |View_Or_Confi|Query_View for view, if |
| | |view is named; |
| | |Query_Subsystem for |
| | |subsystem, |
| | |if configuration is named|
----------------------------------------------------------
| | | |
|Get_Notes |What_Object |Query_View for view |
----------------------------------------------------------
| | | |
|Import |View_To_ |Import_From for imported |
| |Import |view |
| |Into_View |Import_Into for importing|
| | |view |
----------------------------------------------------------
| | | |
|Imported_Views |Of_View |Query_View for view |
----------------------------------------------------------
| | | |
|Information |For_View |Query_View for view |
----------------------------------------------------------
| | | |
|Initial |System_Object|Initial for subsystem |
| |View_To_ |Import_From for view |
| |Import | |
----------------------------------------------------------
| | | |
|Join |What_Object |Join_What for view |
| |To_Which_View|Join_To for view being |
| | |joined to |
----------------------------------------------------------
| | | |
|Make_Code_View |From_View |Make_Code_View for view |
----------------------------------------------------------
| | | |
|Make_Controlled |What_Object |Make_Controlled for view |
| |Join_With_ |Join_To for view joined |
| |View |to, if specified |
----------------------------------------------------------
| | | |
|Make_Path |From_Path |Make_Path for source view|
| |View_To_ |Import_From for imported |
| |Import |view |
| |View_To_ |Import_Into for importing|
| |Modify |view |
----------------------------------------------------------
Table 4 Required Execution Rights for Commands in Package Cmvc (continued)
----------------------------------------------------------
| | | |
|Command |Parameters |Required Execution Right |
----------------------------------------------------------
| | | |
|Make_Spec_View |From_Path |Make_Spec_View for source|
| |View_To_ |view |
| |Import |Import_From for imported |
| |View_To_ |view |
| |Modify |Import_Into for importing|
| | |view |
----------------------------------------------------------
| | | |
|Make_Subpath |From_Path |Make_Subpath for source |
| |View_To_ |view |
| |Import |Import_From for imported |
| |View_To_ |view |
| |Modify |Import_Into for importing|
| | |view |
----------------------------------------------------------
| | | |
|Make_Uncontrolled |What_Object |Make_Uncontrolled for |
| | |view |
----------------------------------------------------------
| | | |
|Merge_Changes |Destination_ |Merge_Changes_Destination|
| |Object |for view |
| |Source_View |Merge_Changes_Source for |
| | |view |
----------------------------------------------------------
| | | |
|Notes |What_Object |Query_View for view |
| | |Edit_Notes for view if |
| | |editing notes |
----------------------------------------------------------
| | | |
|Put_Notes |What_Object |Modify_Notes for view |
----------------------------------------------------------
| | | |
|Release |From_Working_|Release for working view |
| |View |Import_From for imported |
| |Views_To_ |views |
| |Import | |
----------------------------------------------------------
| | | |
|Remove_Import |From_View |Remove_Import for |
| | |importing view |
| | |(Client access to removed|
| | |imports) |
----------------------------------------------------------
| | | |
|Remove_Unused_ |From_View |Remove_Import for |
|Import | |importing view |
| | |(Client access to removed|
| | |imports) |
----------------------------------------------------------
| | | |
|Replace_Model |In_View |Replace_Model for view |
----------------------------------------------------------
| | | |
|Revert |What_Object |Revert for view |
----------------------------------------------------------
| | | |
|Sever |What_Object |Sever for view |
----------------------------------------------------------
| | | |
|Show |Objects |Query_View for view |
----------------------------------------------------------
| | | |
|Show_All_Checked_ |In_View |Query_View for view |
|Out | | |
----------------------------------------------------------
| | | |
|Show_All_ |In_View |Query_View for view |
|Controlled | | |
----------------------------------------------------------
| | | |
|Show_All_ |In_View |Query_View for view |
|Uncontrolled | | |
----------------------------------------------------------
| | | |
|Show_Checked_Out_ |In_View |Query_View for view |
|By_User | | |
----------------------------------------------------------
| | | |
|Show_Checked_Out_ |In_View |Query_View for view |
|In_View | | |
----------------------------------------------------------
| | | |
|Show_History |For_Objects |Query_View for view |
----------------------------------------------------------
| | | |
|Show_History_By_ |For_Objects |Query_View for view |
|Generation | | |
----------------------------------------------------------
| | | |
|Show_Image_Of_ |Object |Query_View for view |
|Generation | | |
----------------------------------------------------------
| | | |
|Show_Out_Of_Date_ |In_View |Query_View for view |
|Objects | | |
----------------------------------------------------------
Table 5 Required Execution Rights for Commands in Package Cmvc_Maintenance
----------------------------------------------------
| | | |
|Command |Parameters |Required Execution Right |
----------------------------------------------------
| | | |
|Check_ |Views |Check_Consistency, if |
|Consistency | |applied to views; |
| | |Subsystem_Check_ |
| | |Consistency, if applied to |
| | |subsystem |
----------------------------------------------------
| | | |
|Destroy_Cdb |Subsystem |Destroy_Cdb for subsystem |
----------------------------------------------------
| | | |
|Display_Cdb |Subsystem |Query_Subsystem for |
| | |subsystem |
----------------------------------------------------
| | | |
|Display_ |View |Query_View for view |
|Code_View | | |
----------------------------------------------------
| | | |
|Expunge_ |In_ |Expunge_Database for |
|Database |Subsystem |subsystem |
----------------------------------------------------
| | | |
|Make_Primary|Subsystem |Make_Primary for subsystem |
----------------------------------------------------
| | | |
|Make_ |Subsystem |Make_Secondary for |
|Secondary | |subsystem |
----------------------------------------------------
| | | |
|Update_Cdb |From_ |No check |
| |Subsystem |Update_Cdb |
| |To_ | |
| |Subsystem | |
----------------------------------------------------
Table 6 Required Execution Rights for Commands in Package Cmvc_Hierarchy
--------------------------------------------------------
| | | |
|Command |Parameters |Required Execution Right |
--------------------------------------------------------
| | | |
|Add_Child |Child |Add_Child_Child for |
| |To_System |subsystem |
| | |Add_Child_Parent for system|
--------------------------------------------------------
| | | |
|Build_ |Working_System_|Build_Activity_In for view |
|Activity |View |containing activity |
| |Views_To_ |Build_Activity_From for |
| |Include |views in activity |
--------------------------------------------------------
| | | |
|Children |Of_System |Query_Subsystem for system |
--------------------------------------------------------
| | | |
|Contents |Of_System_View |Query_View for system view |
--------------------------------------------------------
| | | |
|Expand_ |System_View |Expand_Activity for view |
|Activity | | |
--------------------------------------------------------
| | | |
|Parents |Of_Subsystem |Query_Subsystem for |
| | |subsystem |
--------------------------------------------------------
| | | |
|Remove_Child|Child |(Client access to child) |
| |From_System |Remove_Child for system |
--------------------------------------------------------
Execution Rights, Listed by Access Class
The following tables list the view, subsystem, and system execution rights
that are granted by default when a group is added to a given access class.
These tables are to be read cumulatively, so that, on a given table, the
set of rights for each access class includes the rights for the preceding
access classes. For example, the set of rights granted by the Developer
access class includes the sets of rights granted by the Client Reader
access classes.
Note that operations that affect views check both the access class to the
view and the access class to the subsystem enclosing the view. Therefore,
for each view execution right, the table lists the required access class
to the view's enclosing subsystem.
Table 7 View Execution Rights, Listed by Access Class
---------------------------------------------
| | | |
| | |Required Access|
|View Access|View Execution |Class |
|Class |Rights |to Enclosing |
| | |Subsystem |
---------------------------------------------
| | | |
|Reader |Accept_Changes_ |Developer |
| |Source |Reader |
| |Expand_Activity |Developer |
| |Join_To |Developer |
| |Merge_Changes_ |Reader |
| |Source | |
| |Query_View | |
---------------------------------------------
| | | |
|Client |Build_Activity_ |Reader |
| |From |Reader |
| |Import_From | |
---------------------------------------------
| | | |
|Developer |Abandon_ |Developer |
| |Reservation |Developer |
| |Accept_Changes_ |Reader |
| |Destination |Developer |
| |Build_Activity_In|Developer |
| |Check_In |Owner |
| |Check_Out |Developer |
| |Copy |Owner |
| |Join_What |Developer |
| |Make_Code_View |Owner |
| |Make_Controlled |Owner |
| |Make_Path |Owner |
| |Make_Spec_View |Developer |
| |Make_Subpath |Developer |
| |Make_Uncontrolled|Developer |
| |Merge_Changes_ |Owner |
| |Destination |Developer |
| |Modify_Notes |Developer |
| |Release | |
| |Revert | |
| |Sever | |
---------------------------------------------
| | | |
|Owner |Check_Consistency|Owner |
| |Destroy_View |Owner |
| |Import_Into |Reader |
| |Remove_Import |Reader |
| |Replace_Model |Reader |
---------------------------------------------
Table 8 Subsystem Execution Rights, Listed by Access Class
----------------------------------
| | |
|Subsystem |Subsystem |
|Access Class |Execution Rights |
----------------------------------
| | |
|Reader |Query_Subsystem |
----------------------------------
| | |
|Client |Add_Child_Child |
----------------------------------
| | |
|Developer |Edit_Notes |
| |Update_Cdb |
----------------------------------
| | |
|Owner |Build |
| |Destroy_Cdb |
| |Destroy_Config |
| |Destroy_Subsystem |
| |Expunge_Database |
| |Initial |
| |Make_Primary |
| |Make_Secondary |
| |Subsystem_Check_ |
| |Consistency |
----------------------------------
Table 9 System Execution Rights, Listed by Access Class
--------------------------------
| | |
|System Access|System Execution |
|Class |Rights |
--------------------------------
| | |
|Reader |Query_Subsystem |
--------------------------------
| | |
|Client |Add_Child_Child |
--------------------------------
| | |
|Developer |Add_Child_Parent |
| |Edit_Notes |
| |Remove_Child |
| |Update_Cdb |
--------------------------------
| | |
|Owner |Build |
| |Destroy_Cdb |
| |Destroy_Config |
| |Destroy_Subsystem |
| |Expunge_Database |
| |Initial |
| |Make_Primary |
| |Make_Secondary |
| |Subsystem_Check_ |
| |Consistency |
--------------------------------
@node !Commands.Cmvc_Access_Control.Access_Class
type Access_Class is (Reader, Client, Developer, Owner);
DESCRIPTION
Defines the four access classes to which groups can be assigned - namely, the
Reader, Client, Developer, and Owner access classes.
These access classes define the kinds of access that groups can have to
objects in projects managed under CMVC. As such, they support four general
ways in which groups participate in project development:
* The Reader class is for groups that must be able to inspect and execute
objects in views, subsystems, and systems.
* The Client class is for groups that must be able to import views into
other views.
* The Developer class is for groups that must be able to check in, check
out, edit, and compile objects in views, subsystems, and systems.
* The Owner class is for groups that must have complete control over
views, subsystems, and systems, including the ability to create,
destroy, and change the access to them.
Access classes support these project-development roles by automatically
managing the access lists (ACLs) of the objects in views, subsystems, or
systems. The settings in these ACLs are coordinated to allow groups to
perform certain classes of operations. Access classes also provide a means
of further restricting the execution of CMVC operations even beyond the
limits imposed by the ACL settings.
For a given view, subsystem, or system, a group can be assigned to one of
the four access classes via the Add_Group command. When a group is
assigned to an access class, an entry for the group is automatically added
to the ACL for each of the objects in the view, subsystem, or system. For
objects that are worlds, an entry for the group is also added to the
default ACL. Taken together, the ACL entries for each class grant a
coordinated set of access rights that limit operations on user-created
objects (such as Ada units) as well as on Environment-defined objects (such
as those that manage CMVC state).
Assigning a group to an access class also defines the set of possible
execution rights that can be granted to the group (see type
Execution_Right). Execution rights determine the CMVC operations that
can be performed by members of the group upon a view, subsystem, or
system. Note that a group belonging to a particular access class does not
have any of the permitted execution rights unless these rights have been
explicitly granted (for example, using the Add_Group, Add_Right, or
Set_Rights command).
The four access classes form a hierarchy from Owner (at the top) to
Developer, Client, and Reader (at the bottom). The access provided by a
lower access class is a proper subset of the access provided by the next
higher class.
The four access classes are described below. Each description includes a
list of the access rights that are assigned for objects in views,
subsystems, and systems. For views (including system views), access rights
are assigned for all user- and Environment-managed objects within the
view. The Environment-defined State.Referencers file in a view is of special
interest; the access rights assigned to it determine whether or not the
view can be imported. Note that user-created objects in a view are treated
uniformly with respect to access rights - that is, CMVC access control does
not support setting access rights on an object-by-object or even a
subdirectory-by-subdirectory basis within a view. Thus, a group belonging
to the Reader or Client access class for a view is granted read access (R)
to every user-created object in the view. Similarly, a group belonging to
the Developer or Owner access class for a view is granted read and write
access (RW) to every user-created object in the view. The ACLs of
individual objects must not be changed from their predefined settings (the
Check command can be used to ensure that ACL settings remain as determined
by access classes).
For subsystems, access rights are assigned for all objects in the
subsystem that are not part of any view - for example, the CMVC database,
the compatibility database (CDB), and objects in the Configurations
directory:
* Read access to the CMVC database allows you to browse the controlled
objects in a view, even if you don't have direct access to the view
itself.
* Write access to the CMVC database allows you to check objects in and
out.
* Write access to the CDB allows you to compile new unit specifications in
the subsystem's views (with less than write access, you can recompile
only new bodies and existing specifications).
* Write access to configurations is required to destroy views and expunge
the CMVC database.
For systems, access rights are assigned for all objects that are not part
of any system view. This includes the system's CMVC database (which
controls any programs that are maintained in the system) as well as the
State.Children file (which allows children to be added to the system).
ENUMERATIONS
Reader
Grants read access to objects in a view, subsystem, or system. For a view,
the Reader access class grants sufficient access to display objects in the
view and to execute any compiled units in it. For a subsystem, this access
class grants sufficient access to use the CMVC editor to browse the
controlled objects in any of the subsystem's views, regardless of whether
access has been granted to the view itself.
When a group is assigned to the Reader access class for a view, the
following access rights are granted to the group:
-------------------------------------
| | |
|View Objects |Reader Access |
| |Rights |
| | |
|View (World) |R access, R |
| |default access |
| | |
| |R access |
|.State.Referencers | |
|(File) | |
| | |
| All other objects|R access |
|in view | |
-------------------------------------
When a group is assigned to the Reader access class for a subsystem or
system, the following access rights are granted to the group:
-------------------------------------
| | |
|Subsystem/System |Reader Access |
|Objects |Rights |
| | |
|Subsystem/System |R access, R |
|(World) |default access |
| | |
| .Configurations | |
|(Directory) | |
| | |
| All objects |R access |
|in directory | |
| | |
| .State | |
|(Directory) | |
| | |
| .Compatibility |R access, R |
|(World) |default access |
| | |
| All |R access |
|objects in world | |
| | |
| .Cmvc_Database|R access |
|(File) | |
| | |
| .Parents |R access |
|(File) | |
| | |
| .Children |R access |
|(File) | |
| | |
| All other |R access |
|objects in directory | |
| | |
|All other objects in |R access |
|(sub)system | |
-------------------------------------
Client
Superset of Reader access class. For a view, the Client access class
grants sufficient access to allow the view to be imported into other views.
Note that Client access to a view is required only for those groups whose
users actually need to add the view to (or remove the view from) the
imports of other views.
For a subsystem, this access class grants sufficient access to allow the
subsystem to be made a child of a system.
When a group is assigned to the Client access class for a view, the
following access rights are granted to the group:
-------------------------------------
| | |
|View Objects |Client Access |
| |Rights |
| | |
|View (World) |R access, R |
| |default access |
| | |
| |RW access |
|.State.Referencers | |
|(File) | |
| | |
| All other objects|R access |
|in view | |
-------------------------------------
When a group is assigned to the Client access class for a subsystem or
system, the following access rights are granted to the group:
-------------------------------------
| | |
|Subsystem/System |Client Access |
|Objects |Rights |
| | |
|Subsystem/System |R access, R |
|(World) |default access |
| | |
| .Configurations | |
|(Directory) | |
| | |
| All objects |R access |
|in directory | |
| | |
| .State | |
|(Directory) | |
| | |
| .Compatibility|R access, R |
|(World) |default access |
| | |
| All |R access |
|objects in world | |
| | |
| .Cmvc_Database|R access |
|(File) | |
| | |
| .Parents |RW access |
|(File) | |
| | |
| .Children |R access |
|(File) | |
| | |
| All other |R access |
|objects in directory | |
| | |
|All other objects in |R access |
|(sub)system | |
-------------------------------------
Developer
Superset of Client access class. For a view, the Developer access class
grants sufficient additional access to allow objects in the view to be
modified and to allow new objects to be created. For a subsystem, this
access class grants sufficient additional access to allow compatibility
objects and the CMVC database to be modified.
Note that you must have Developer access to a subsystem to check out
objects in the subsystem's views, because checkin and checkout operations
modify the CMVC database.
When a group is assigned to the Developer access class for a view, the
following access rights are granted to the group:
--------------------------------------
| | |
|View Objects |Developer Access|
| |Rights |
| | |
|View (World) |RC access, RW |
| |default access |
| | |
| |RW access |
|.State.Referencers | |
|(File) | |
| | |
| All other objects|RW access |
|in view | |
--------------------------------------
When a group is assigned to the Developer access class for a subsystem or
system, the following access rights are granted to the group:
--------------------------------------
| | |
|Subsystem/System |Developer Access|
|Objects |Rights |
| | |
|Subsystem/System |R access, R |
|(World) |default access |
| | |
| .Configurations | |
|(Directory) | |
| | |
| All objects |R access |
|in directory | |
| | |
| .State | |
|(Directory) | |
| | |
| .Compatibility|RC access, RW |
|(World) |default access |
| | |
| All |RW access |
|objects in world | |
| | |
| .Cmvc_Database|RW access |
|(File) | |
| | |
| .Parents |RW access |
|(File) | |
| | |
| .Children |RW access |
|(File) | |
| | |
| All other |R access |
|objects in directory | |
| | |
|All other objects in |RW access |
|(sub)system | |
--------------------------------------
Owner
Superset of Developer access class. For a view, the Owner access class
provides all possible access to the view and the objects in it. You must
have Owner access to a view in order to change its imports or destroy it.
To change a view's access-control characteristics, you must have either
Owner access to the view or Owner access to the subsystem enclosing it.
For a subsystem, the Owner access class provides all possible access to
the subsystem and the objects in it. You must have Owner access to a
subsystem to create new views in it or to destroy it. To change a
subsystem's access-control characteristics, you must have either Owner
access to the subsystem or the owner access right (O) to the world
enclosing the subsystem.
When a group is assigned to the Owner access class for a view, the
following access rights are granted to the group:
-------------------------------------
| | |
|View Objects |Owner Access |
| |Rights |
| | |
|View (World) |RCOD access, RW|
| |default access |
| | |
| |RW access |
|.State.Referencers | |
|(File) | |
| | |
| All other objects|RW access |
|in view | |
-------------------------------------
When a group is assigned to the Owner access class for a subsystem or
system, the following access rights are granted to the group:
-------------------------------------
| | |
|Subsystem/System |Owner Access |
|Objects |Rights |
| | |
|Subsystem/System |RCOD access, RW|
|(World) |default access |
| | |
| .Configurations | |
|(Directory) | |
| | |
| All objects |RW access |
|in directory | |
| | |
| .State | |
|(Directory) | |
| | |
| .Compatibility|RCOD access, RW|
|(World) |default access |
| | |
| All |RW access |
|objects in world | |
| | |
| .Cmvc_Database|RW access |
|(File) | |
| | |
| .Parents |RW access |
|(File) | |
| | |
| .Children |RW access |
|(File) | |
| | |
| All other |RW access |
|objects in directory | |
| | |
|All other objects in |RW access |
|(sub)system | |
-------------------------------------
@node !Commands.Cmvc_Access_Control.Add_Group
procedure Add_Group
(The_Group : String := "NETWORK_PUBLIC";
In_Class : Access_Class := Cmvc_Access_Control.Reader;
View_Or_Subsystem : String := "<SELECTION>";
Add_Execution_Rights : Boolean := True;
Response : String := "<PROFILE>");
DESCRIPTION
Adds a group to the specified access class for the designated view,
subsystem, or system; up to seven groups can have access to a given view,
subsystem, or system at any one time.
If the specified group already belongs to an access class for the
designated view, subsystem, or system, the group is automatically removed
from its old access class and assigned to the new one.
Access classes define the kinds of access that groups can have to objects
in projects developed under CMVC. When a group is assigned to an access
class for a given view, subsystem, or system, that group is granted
specific access rights as described in the reference entry for type
Access_Class. Access rights are granted by automatically inserting an
entry for the group into each object's ACL. The four access classes and
the specific access rights they grant are described under type
Access_Class.
Each access class also defines the set of possible execution rights that
can be granted to the group for the specified view, subsystem, or system.
(The execution rights permitted by each access class are listed under
"Reference Summary for Package Cmvc_Access_Control" in the introduction to
this package.) By default, the Add_Group command causes all of the
permitted execution rights to be granted to the group. Once granted,
individual execution rights can be removed subsequently using the
Remove_Right command.
Alternatively, the Add_Execution_Rights parameter can be set to false so
that no execution rights are granted when a group is added to an access
class. Individual execution rights can be granted subsequently using the
Add_Right procedure.
When this command removes a group from one access class in order to add it
to another, the access lists (ACLs) for the affected objects are adjusted
appropriately, and all inappropriate execution rights are automatically
removed, regardless of the value of the Add_Execution_Rights parameter.
PARAMETERS
The_Group : String := "NETWORK_PUBLIC";
Specifies the name of the group to be added to the specified access class.
Only one group can be named. The default group is Network_Public.
In_Class : Access_Class := Cmvc_Access_Control.Reader;
Specifies the access class to which the specified group is assigned. One of
four access classes can be specified - namely, Reader, Client, Developer, or
Owner. The default is the Reader access class, which provides the least
amount of access.
View_Or_Subsystem : String := "<SELECTION>";
Specifies one or more views, subsystems, or systems to which the specified
group is granted access. Multiple views, subsystems, or systems can be
specified using wildcards, context characters, set notation, indirect
files, and attributes. The default is the highlighted view, subsystem, or
system, provided that the highlight contains the cursor.
Add_Execution_Rights : Boolean := True;
Specifies whether the execution rights permitted by the specified access
class are to be granted. When true (the default), all permitted execution
rights are granted to the specified group. When false, none of the
permitted execution rights are granted to the specified group.
Response : String := "<PROFILE>";
Specifies how to respond to errors, how to generate logs, and what
activities and switches to use during the execution of this command. The
default is the job response profile.
RESTRICTIONS
To add a group to an access class for a view, you must have either Owner
access to the view or Owner access to the subsystem enclosing it.
To add a group to an access class for a subsystem, you must have either
Owner access to the subsystem or the owner access right (O) to the world
enclosing the subsystem.
ERRORS
The Add_Group command must obtain write locks on the objects whose ACLs
are to be set. This command will fail if it cannot obtain all of the
necessary write locks (for example, if someone is currently editing one of
the affected objects). As a result, the group is not added to the access
class and no ACLs are changed.
EXAMPLES
Assume that you have Owner access for a subsystem called Algorithms and
you want to add a group called Client_Of_Algorithms to the Client access
class for every view in the subsystem. Assume further that you want this
group to have all of the available execution rights. The following
command, executed from the context Algorithms, accomplishes this:
Cmvc_Access_Control.Add_Group
(The_Group => "read_all",
In_Class => cmvc_access_control.client,
View_Or_Subsystem => "@'c(spec_view,load_view)");
Assume that you have Owner access for the subsystem Algorithms and you
want to add a group called Read_All to the Reader access class for a new
view called Algorithms.Rev2_0_Spec. Assume further that you do not want
this group to have any of the available execution rights. The following
command accomplishes this, assuming that you have selected the library
entry for Rev2_0_Spec:
Cmvc_Access_Control.Add_Group (The_Group => "read_all",
In_Class => cmvc_access_control.reader,
View_Or_Subsystem => "<SELECTION>",
Add_Execution_Rights => False);
REFERENCES
type Access_Class
procedure Add_Right
procedure Remove_Group
procedure Remove_Right
@node !Commands.Cmvc_Access_Control.Add_Right
procedure Add_Right
(For_Group : String := "NETWORK_PUBLIC";
The_Right : Execution_Right := Cmvc_Access_Control.All_Rights;
View_Or_Subsystem : String := "<SELECTION>";
Response : String := "<PROFILE>");
DESCRIPTION
Grants the specified execution right to the specified group for the
designated view, subsystem, or system.
An execution right can be granted only if it is permitted by the access
class to which the group belongs. (See "Reference Summary for Package
Cmvc_Access_Control" in the introduction to this package for the list of
execution rights permitted by each access class for views, subsystems, and
systems.) By default, this procedure grants a group all of the permitted
execution rights.
PARAMETERS
For_Group : String := "NETWORK_PUBLIC";
Specifies the name of the group to which an execution right is to be
granted. Only one group can be named. The default group is Network_Public.
The_Right : Execution_Right := Cmvc_Access_Control.All_Rights;
Specifies the execution right to be granted to the group. By default, the
procedure grants all rights that are permitted by the access class to
which the group belongs. If the default value is not used, only a single
execution right can be specified.
View_Or_Subsystem : String := "<SELECTION>";
Specifies the views, subsystems, or systems to which the specified execution
right(s) apply. Multiple views, subsystems, or systems can be specified
using wildcards, context characters, set notation, indirect files, and
attributes. The default is the highlighted view, subsystem, or system,
provided that the highlight contains the cursor.
Response : String := "<PROFILE>";
Specifies how to respond to errors, how to generate logs, and what
activities and switches to use during the execution of this command. The
default is the job response profile.
RESTRICTIONS
To grant an execution right to a group for a view, you must have Owner
access to the view.
To grant an execution right to a group for a subsystem, you must have
Owner access to the subsystem.
EXAMPLES
Assume that a group called Read_All belongs to the Reader access class for
a view but has been granted none of the execution rights for that class.
Assume further that you, the view's Owner, want members of this group to
be able to obtain information about the view using the Cmvc.Edit command.
To do this, you must grant this group the Query_View execution right. The
following command accomplishes this, provided that the appropriate view is
selected:
Cmvc_Access_Control.Add_Right (For_Group => "Read_All",
The_Right =>
Cmvc_Access_Control.Query_View,
View_Or_Subsystem => "<SELECTION>");
REFERENCES
type Execution_Right
function Has_Right
procedure Remove_Right
@node !Commands.Cmvc_Access_Control.Check
procedure Check (View_Or_Subsystem : String := "<SELECTION>";
Repair_Inconsistencies : Boolean := False;
Response : String := "<PROFILE>");
DESCRIPTION
Checks whether:
* Objects in the specified views, subsystems, or systems have access lists
(ACLs) that are consistent with the current CMVC access-class
assignments.
* The groups that have access to these views, subsystems, or systems
still exist.
This command optionally repairs any ACL inconsistencies and expunges any
deleted groups.
When groups are assigned to CMVC access classes for views, subsystems, and
systems, ACLs for the individual objects are set. However, a user with
Owner access or operator capability can subsequently use operations in
packages Access_List and Access_List_Tools to reset the ACLs of individual
objects. Resetting individual ACLs can cause a group to have more or less
access than is warranted by its access class. Insufficient access causes
the desired CMVC operations to fail. By default, the Check procedure
quits after finding the first ACL inconsistency, displaying:
* A warning message if the group's actual access is greater than is
warranted by its access class.
* An error message if the group's actual access is less than is warranted
by its access class.
Similarly, a user with operator capability can delete a group after it has
been assigned to an CMVC access class. The Check procedure displays an
error message if it encounters a deleted group among access-class
assignments.
If the Repair_Inconsistencies parameter is set to true:
* All deleted groups are removed from access-class assignments. It is
recommended that you execute this command every time a group is deleted
from the Environment.
* All inconsistent ACLs are reset so that the correct access rights are
assigned to each group. (See the Access_Class type for the access
rights associated with each access class.)
You must have Owner access to the views, subsystems, or systems in which
inconsistencies are repaired. Alternatively, you can enable privileges.
A related function, Is_Consistent, performs the same checks, returning a
Boolean value. It does not produce messages or attempt to repair ACLs.
PARAMETERS
View_Or_Subsystem : String := "<SELECTION>";
Specifies one or more views, subsystems, or systems whose ACLs are to be
checked. Multiple views, subsystems, or systems can be specified using
wildcards, context characters, set notation, indirect files, and
attributes. The default is the highlighted view, subsystem, or system,
provided that the highlight contains the cursor.
Repair_Inconsistencies : Boolean := False;
Specifies whether to repair inconsistent ACLs and remove deleted groups in
the specified views, subsystems, or systems. When false (the default), no
action is taken other than displaying error or warning messages. When
true, deleted groups are removed from ACLs and ACLs are changed so that
the groups in each access class have the correct access rights to the
relevant objects.
Response : String := "<PROFILE>";
Specifies how to respond to errors, how to generate logs, and what
activities and switches to use during the execution of this command. The
default is the job response profile.
RESTRICTIONS
To repair inconsistencies in a view, you must have either Owner access to
the view or Owner access to the subsystem enclosing it. To repair
inconsistencies in a subsystem, you must have either Owner access to the
subsystem or the owner access right (O) to the world enclosing the
subsystem. Alternatively, you may perform either operation with
privileges enabled.
ERRORS
To repair inconsistencies, the Check command must obtain write locks on
the objects whose ACLs are to be reset. This command will fail if it
cannot obtain all of the necessary write locks (for example, if someone is
currently editing one of the affected objects). As a result, inconsis-
tencies in the view, subsystem, or system are not repaired and no ACLs are
changed.
REFERENCES
function Is_Consistent
LM, package Access_List
LM, package Access_List_Tools
@node !Commands.Cmvc_Access_Control.Display
procedure Display (For_Group : String := "<ALL>";
View_Or_Subsystem : String := "<CURSOR>";
Execution_Rights : Boolean := False;
Response : String := "<PROFILE>");
DESCRIPTION
Displays the current access-control information pertaining to the specified
group for the designated view, subsystem, or system; the information is
displayed in the current output window.
By default, this procedure displays the access classes for all groups that
have access to the specified view, subsystem, or system. If the
Execution_Rights parameter is set to true, then the procedure also
displays the execution rights that have been granted to these groups.
PARAMETERS
For_Group : String := "<ALL>";
Specifies the group for which access-control information is to be
displayed. The default special value "<ALL>" causes information to be
displayed for all groups that have access to the specified view, subsystem,
or system. If the default value is not used, only a single group name can
be specified.
View_Or_Subsystem : String := "<CURSOR>";
Specifies the view, subsystem, or system for which access-control
information is to be displayed. Multiple views, subsystems, or systems can
be specified using wildcards, context characters, set notation, indirect
files, and attributes. The default is the view, subsystem, or system
indicated by the cursor.
Execution_Rights : Boolean := False;
Specifies whether to display the execution rights that have been granted to
the specified group for the specified view, subsystem, or system. When false
(the default), the execution rights are not displayed.
Response : String := "<PROFILE>";
Specifies how to respond to errors, how to generate logs, and what
activities and switches to use during the execution of this command. The
default is the job response profile.
RESTRICTIONS
To display the access-control information for a view or subsystem, you
must have at least Reader access to that view or subsystem.
EXAMPLES
Assume that you want to find out who has access to the view Rev1_Working in
the subsystem !Projects.Planetary_Motion.Demo. The following command,
entered with default values, accomplishes this, provided that the cursor
is on the desired view:
Cmvc_Access_Control.Display;
As a result, the following appears in the current output window:
Access Control Group List for View
!PROJECTS.PLANETARY_MOTION.DEMO.REV1_WORKING
PROJECT_LEADER : OWNER
FRED : OWNER
MARY : READER
Assume that you only want to know what access Mary has to this view.
Furthermore, you want to know what execution rights she has. The following
command accomplishes this:
Cmvc_Access_Control.Display (For_Group => "Mary",
View_Or_Subsystem => "<CURSOR>",
Execution_Rights => True);
As a result, the following appears in the current output window:
Access Control Group List for View
!PROJECTS.PLANETARY_MOTION.DEMO.REV1_WORKING
MARY : READER
ACCEPT_CHANGES_SOURCE
JOIN_TO
MERGE_CHANGES_SOURCE
QUERY_VIEW
EXPAND_ACTIVITY
@node !Commands.Cmvc_Access_Control.Execution_Right
type Execution_Right is new Natural range 0 .. 127;
DESCRIPTION
Defines the execution rights that can be granted to groups for views,
subsystems, or systems.
Execution rights determine the CMVC operations that can be performed by
members of the group upon a view, subsystem, or system. Each execution
right is represented by a constant of this type; these constants are
listed below.
Execution rights provide control over the primitive operations in the
commands from packages Cmvc, Cmvc_Maintenance, and Cmvc_Hierarchy. A
primitive operation is a distinct portion of a command that applies to
(references or affects) a particular view, subsystem, or system.
Accordingly, a command has one primitive operation associated with each
parameter that names a view, subsystem, or system. For example, the
Cmvc.Accept_Changes command has two primitive operations, one that applies
to the view named by the Source parameter and one that applies to the view
named by the Destination parameter.
Execution rights are the mechanism that permits a group to apply a
particular primitive operation to a particular view, subsystem, or system.
Thus, to execute a given CMVC command, a group must have the appropriate
execution right to each structure that is affected by the command's
primitive operations. For example, a group must have the Check_In and
Check_Out execution rights to a view to perform checkin and checkout
operations in that view. Similarly, if the group is to accept changes from
one view to another, it must have the Accept_Changes_Source and
Accept_Changes_Destination execution rights to the source and destination
views, respectively. Because there is an execution right corresponding to
each primitive operation, a given group typically has a set of execution
rights for each view, subsystem, or system to which it has access.
The access class to which a group belongs defines the set of possible
execution rights that can be granted to the group. ("Reference Summary for
Package Cmvc_Access_Control" in the introduction to this package lists
the execution rights that are permitted by each access class.) However, a
group has only those execution rights that have been explicitly granted to
it. You can grant a group the entire set of eligible execution rights when
you use the Add_Group command to add the group to an access class.
Alternatively, you can grant a group a subset of the eligible execution
rights using the Add_Right or Set_Rights command, and you can revoke
individual execution rights using the Remove_Right command.
The constants that represent execution rights are listed in alphabetical
order below. In general, the name of each execution right is the same as
the name of the primitive operation it governs. (The name of a primitive
operation is formed by concatenating the name of the associated command
with the name of the relevant parameter, if there is one.)
The description for each execution right indicates whether the execution
right applies to a view, a subsystem, or a system. Execution rights that
control primitive operations on views are called view execution rights.
Similarly, execution rights that apply to subsystems and systems are
called subsystem execution rights and system execution rights,
respectively.
Also specified in each description is the minimum access class to which a
group must belong to be eligible for that execution right. Note that an
execution right pertaining to a view requires not only a minimum access
class to that view, but also a minimum access class for the subsystem that
encloses the view. The access class for the view is checked at the time
the execution right is granted; the access class for the subsystem is
checked only when you execute a command that applies the relevant
primitive operation.
Constants
Abandon_Reservation : constant Execution_Right := 5;
View execution right. Permits a group to use the Cmvc.Abandon_Reservation
command on objects in a view.
Minimum access class for view: Developer
Minimum access class for enclosing subsystem: Developer
Accept_Changes_Destination : constant Execution_Right := 3;
View execution right. Permits a group to accept changes into a view (that
is, to name the view as the destination of the Cmvc.Accept_Changes
command).
Minimum access class for view: Developer
Minimum access class for enclosing subsystem: Developer
Accept_Changes_Source : constant Execution_Right := 4;
View execution right. Permits a group to accept changes from a view (that
is, to name the view or objects in it in the Source parameter of the
Cmvc.Accept_Changes command).
Minimum access class for view: Reader
Minimum access class for enclosing subsystem: Developer
Add_Child_Child : constant Execution_Right := 44;
Subsystem/system execution right. Permits a group to make a subsystem or
system a child of another system (that is, to name the subsystem or system
in the Child parameter of the Cmvc_Hierarchy.Add_Child command).
Minimum access class for subsystem/system: Developer
Add_Child_Parent : constant Execution_Right := 43;
System execution right. Permits a group to make a system a parent of a
subsystem or another system (that is, to name the system in the To_System
parameter of the Cmvc_Hierarchy.Add_Child command).
Minimum access class for system: Developer
All_Rights : constant Execution_Right := 0;
Grants a group all execution rights that are appropriate, given the access
class for which the group belongs.
Build : constant Execution_Right := 34;
Subsystem/system execution right. Permits a group to build views from
configurations within a subsystem or system (that is, to name a
configuration from the subsystem or system in the Cmvc.Build command).
Minimum access class for subsystem/system: Owner
Build_Activity_From : constant Execution_Right := 29;
View execution right. Permits a group to include a view in the release
activity of a system view (that is, to name the view in the
Views_To_Include parameter of the Cmvc_Hierarchy.Build_Activity
command).
Minimum access class for view: Client
Minimum access class for enclosing subsystem: Reader
Build_Activity_In : constant Execution_Right := 28;
View execution right. Permits a group to build a release activity in a
system view (that is, to name the system view in the Working_System_View
parameter of the Cmvc_Hierarchy.Build_Activity command).
Minimum access class for view: Developer
Minimum access class for enclosing subsystem: Reader
Check_Consistency : constant Execution_Right := 27;
View execution right. Permits a group to check the consistency of a view
(that is, to name the view in the Views parameter of the
Cmvc_Maintenance.Check_Consistency command).
Minimum access class for view: Owner
Minimum access class for enclosing subsystem: Owner
Check_In : constant Execution_Right := 2;
View execution right. Permits a group to check in objects in a view using
the Cmvc.Check_In command.
Minimum access class for view: Developer
Minimum access class for enclosing subsystem: Developer
Check_Out : constant Execution_Right := 1;
View execution right. Permits a group to check out objects in a view
using the Cmvc.Check_Out command.
Minimum access class for view: Developer
Minimum access class for enclosing subsystem: Developer
Copy : constant Execution_Right := 16;
View execution right. Permits a group to copy a view using the Cmvc.Copy
command.
Minimum access class for view: Developer
Minimum access class for enclosing subsystem: Owner
Destroy_Cdb : constant Execution_Right := 42;
Subsystem/system execution right. Permits a group to destroy a
subsystem's or system's compatibility database using the
Cmvc_Maintenance.Destroy_Cdb command.
Minimum access class for subsystem/system: Owner
Destroy_Config : constant Execution_Right := 32;
Subsystem/system execution right. Permits a group to destroy a
configuration object in a subsystem or system using the Cmvc.Destroy_View
command.
Minimum access class for subsystem/system: Owner
Destroy_Subsystem : constant Execution_Right := 33;
Subsystem/system execution right. Permits a group to destroy a subsystem
or system using the Cmvc.Destroy_Subsystem command.
Minimum access class for subsystem/system: Owner
Destroy_View : constant Execution_Right := 24;
View execution right. Permits a group to destroy a view using the
Cmvc.Destroy_View command. Note that the Destroy_Config execution right to
the subsystem is also required to destroy a view's configuration object as
well.
Minimum access class for view: Owner
Minimum access class for enclosing subsystem: Owner
Edit_Notes : constant Execution_Right := 36;
Subsystem/system execution right. Permits a group to modify notes in a
subsystem or system using the CMVC editor.
Minimum access class for subsystem/system: Developer
Expand_Activity : constant Execution_Right := 30;
View execution right. Permits a group to expand a system view's release
activity using the Cmvc_Hierarchy.Expand_Activity command.
Minimum access class for view containing source activity: Reader
Minimum access class for view to contain expanded activity: Developer
Minimum access class for enclosing subsystem: Reader
Expunge_Database : constant Execution_Right := 37;
Subsystem/system execution right. Permits a group to expunge a
subsystem's or system's CMVC database using the
Cmvc_Maintenance.Expunge_Database command.
Minimum access class for subsystem/system: Owner
Import_From : constant Execution_Right := 20;
View execution right. Permits a group to import a view (that is, to name
the view in the View_To_Import parameter in commands such as Cmvc.Import,
Cmvc.Copy, Cmvc.Make_Path, and so on).
Minimum access class for imported view: Client
Minimum access class for enclosing subsystem: Reader
Import_Into : constant Execution_Right := 21;
View execution right. Permits a group to change a view's imports (that
is, to name the view in the Into_View parameter of the Cmvc.Import command
or in the View_To_Modify parameter in commands such as Cmvc.Copy,
Cmvc.Make_Path, and so on).
Minimum access class for view: Owner
Minimum access class for enclosing subsystem: Reader
Initial : constant Execution_Right := 31;
Subsystem/system execution right. Permits a group to create an empty view
in a subsystem or system using the Cmvc.Initial command.
Minimum access class for subsystem/system: Owner
Join_To : constant Execution_Right := 12;
View execution right. Permits a group to name a view in the To_Which_View
parameter of the Cmvc.Join command.
Minimum access class for view: Reader
Minimum access class for enclosing subsystem: Developer
Join_What : constant Execution_Right := 11;
View execution right. Permits a group to name objects in a view in the
What_Object parameter of the Cmvc.Join command.
Minimum access class for view: Developer
Minimum access class for enclosing subsystem: Developer
Make_Code_View : constant Execution_Right := 25;
View execution right. Permits a group to create a code view from a view
using the Cmvc.Make_Code_View command.
Minimum access class for view: Developer
Minimum access class for enclosing subsystem: Owner
Make_Controlled : constant Execution_Right := 8;
View execution right. Permits a group to make objects in a view
controlled using the Cmvc.Make_Controlled command.
Minimum access class for view: Developer
Minimum access class for enclosing subsystem: Developer
Make_Path : constant Execution_Right := 17;
View execution right. Permits a group to copy a view to make a new
development path, using the Cmvc.Make_Path command.
Minimum access class for view: Developer
Minimum access class for enclosing subsystem: Owner
Make_Primary : constant Execution_Right := 40;
Subsystem/system execution right. Permits a group to convert a secondary
subsystem or system into a primary subsystem or system, using the
Cmvc_Maintenance.Make_Primary command.
Minimum access class for subsystem/system: Owner
Make_Secondary : constant Execution_Right := 41;
Subsystem/system execution right. Permits a group to convert a primary
subsystem or system into a secondary subsystem or system, using the
Cmvc_Maintenance.Make_Secondary command.
Minimum access class for subsystem/system: Owner
Make_Spec_View : constant Execution_Right := 19;
View execution right. Permits a group to make a spec view from a view
using the Cmvc.Make_Spec_View command.
Minimum access class for view: Developer
Minimum access class for enclosing subsystem: Owner
Make_Subpath : constant Execution_Right := 18;
View execution right. Permits a group to make a subpath from a view using
the Cmvc.Make_Subpath command.
Minimum access class for view: Developer
Minimum access class for enclosing subsystem: Owner
Make_Uncontrolled : constant Execution_Right := 9;
View execution right. Permits a group to make objects in a view
uncontrolled using the Cmvc.Make_Uncontrolled command.
Minimum access class for view: Developer
Minimum access class for enclosing subsystem: Developer
Merge_Changes_Destination : constant Execution_Right := 13;
View execution right. Permits a group to merge changes into an object in
a view (that is, to name the object in the Destination_Object parameter of
the Cmvc.Merge_Changes command).
Minimum access class for view: Developer
Minimum access class for enclosing subsystem: Developer
Merge_Changes_Source : constant Execution_Right := 14;
View execution right. Permits a group to merge changes from an object in
a view (that is, to name the object in the Source_Object parameter of the
Cmvc.Merge_Changes command).
Minimum access class for view: Reader
Minimum access class for enclosing subsystem: Developer
Modify_Notes : constant Execution_Right := 7;
View execution right. Permits a group to modify the notes of objects in a
view using the Cmvc.Put_Notes or Cmvc.Append_Notes command.
Minimum access class for view: Developer
Minimum access class for enclosing subsystem: Developer
Query_Subsystem : constant Execution_Right := 35;
Subsystem/system execution right. Permits a group to obtain information
about a subsystem or system using the Cmvc_Maintenance.Display_Cdb
command. This execution right also permits a group to obtain information
from a configuration in a subsystem using the Cmvc.Edit command. Finally,
this execution right permits a group to obtain information about a system
using the Cmvc_Hierarchy.Children and Cmvc_Hierarchy.Parents commands.
Minimum access class for subsystem/system: Reader
Query_View : constant Execution_Right := 26;
View execution right. Permits a group to obtain various kinds of
information about a view using commands from package Cmvc such as
Get_Notes, Imported_Views, Information, Edit, Notes, Def, Compare, and all
the commands beginning with Show_ (for example, Show_History). This
execution right also permits a group to name a view in the
Cmvc_Maintenance.Display_Code_View command and to name a system view in
the Cmvc_Hierarchy.Contents command.
Minimum access class for view: Reader
Minimum access class for enclosing subsystem: Reader
Release : constant Execution_Right := 15;
View execution right. Permits a group to create a release from a view
using the Cmvc.Release command.
Minimum access class for view: Developer
Minimum access class for enclosing subsystem: Owner
Remove_Child : constant Execution_Right := 45;
System execution right. Permits a group to remove a child from a system
(that is, to name the system in the From_System parameter of the
Cmvc_Hierarchy.Remove_Child command).
Minimum access class for system: Developer
Remove_Import : constant Execution_Right := 22;
View execution right. Permits a group to remove an import from a view
using the Cmvc.Remove_Import or Cmvc.Remove_Unused_Import command.
Minimum access class for view: Owner
Minimum access class for enclosing subsystem: Reader
Replace_Model : constant Execution_Right := 23;
View execution right. Permits a group to replace a view's model using the
Cmvc.Replace_Model command.
Minimum access class for view: Owner
Minimum access class for enclosing subsystem: Reader
Revert : constant Execution_Right := 6;
View execution right. Permits a group to revert objects in a view to a
previous generation using the Cmvc.Revert command.
Minimum access class for view: Developer
Minimum access class for enclosing subsystem: Developer
Sever : constant Execution_Right := 10;
View execution right. Permits a group to use the Cmvc.Sever command to
sever objects in a view from the objects to which they are joined.
Minimum access class for view: Developer
Minimum access class for enclosing subsystem: Developer
Subsystem_Check_Consistency : constant Execution_Right := 38;
Subsystem/system execution right. Permits a group to check the
consistency of all of the views in a subsystem or all the system views in
a system (that is, to name the subsystem or system in the
Cmvc_Maintenance.Check_Consistency command).
Minimum access class for subsystem/system: Owner
Update_Cdb : constant Execution_Right := 39;
Subsystem/system execution right. Permits a group to update the
compatibility database of a secondary subsystem or system using the
Cmvc_Maintenance.Update_Cdb command.
Minimum access class for subsystem/system: Developer
REFERENCES
procedure Add_Group
procedure Add_Right
function Has_Right
procedure Remove_Right
procedure Set_Rights
@node !Commands.Cmvc_Access_Control.Execution_Table
type Execution_Table is array (Execution_Right) of Boolean;
DESCRIPTION
Defines a structure called an execution table, which can be used to specify
a complete set of execution rights for a group.
Execution tables allow execution rights to be granted as sets rather than
individually. The Set_Rights command can be used to grant the rights
specified in an execution table.
Execution tables are intended for use in site-specific tools that manage
CMVC access control. Such tools might define constants of type
Execution_Table to represent site-specific policies regarding execution
rights. Note, however, that execution tables are subject to the access
permitted by access classes, so that site-specific tools can grant only the
execution rights that are appropriate to a group's access class.
The sets of execution rights that are permitted by each access class are
listed in the introduction to this package. Each set is also represented
by a predefined constant of type Execution_Table. These constants are
documented on their own reference-entry pages. One group of constants
represents the execution rights for subsystems and systems. Two groups of
constants represent the execution rights for views, because view execution
rights check for access to a view as well as to the subsystem enclosing
the view.
The following constants represent the subsystem (and system) execution
rights that are permitted by each access class:
Subsystem_Reader_Rights
Subsystem_Client_Rights
Subsystem_Developer_Rights
Subsystem_Owner_Rights
The following constants represent the view execution rights permitted by
access classes for views and their enclosing subsystems:
View_Reader_Rights Subsystem_Reader_View_Rights
View_Client_Rights Subsystem_Client_View_Rights
View_Developer_Rights Subsystem_Developer_View_Rights
View_Owner_Rights Subsystem_Owner_View_Rights
REFERENCES
type Execution_Right
function Get_Rights
procedure Set_Rights
constant Subsystem_Client_Rights
constant Subsystem_Client_View_Rights
constant Subsystem_Developer_Rights
constant Subsystem_Developer_View_Rights
constant Subsystem_Owner_Rights
constant Subsystem_Owner_View_Rights
constant Subsystem_Reader_Rights
constant Subsystem_Reader_View_Rights
constant View_Client_Rights
constant View_Developer_Rights
constant View_Owner_Rights
constant View_Reader_Rights
@node !Commands.Cmvc_Access_Control.Get_Access
function Get_Access
(The_Group : String := "NETWORK_PUBLIC";
View_Or_Subsystem : String := "<CURSOR>";
Response : String := "<WARN>") return Access_Class;
DESCRIPTION
Returns the specified group's access class for the designated view,
subsystem, or system.
If the group does not belong to an access class for the designated object,
the No_Access exception is raised.
This function is intended for use in site-specific tools that manage CMVC
access control.
PARAMETERS
The_Group : String := "NETWORK_PUBLIC";
Specifies the group whose access class is to be returned. Only one group
can be named.
View_Or_Subsystem : String := "<CURSOR>";
Specifies the view, subsystem, or system for which the specified group's
access class is to be returned. Wildcards, context characters, and
attributes may be used, provided that the name resolves to a single view,
subsystem, or system. The default is the view, subsystem, or system
indicated by the cursor.
Response : String := "<WARN>";
Specifies how to respond to errors, how to generate logs, and what
activities and switches to use during the execution of this command. The
default is a profile that logs only warnings, errors, and exceptions.
return Access_Class;
Returns the specified group's access class for the designated view,
subsystem, or system. If the group does not belong to an access class for
the designated object, the No_Access exception is raised.
REFERENCES
exception No_Access
@node !Commands.Cmvc_Access_Control.Get_Rights
function Get_Rights
(For_Group : String := "NETWORK_PUBLIC";
View_Or_Subsystem : String := "<CURSOR>";
Response : String := "<WARN>") return Execution_Table;
DESCRIPTION
Returns the set of execution rights that have been granted to a group for
the designated view, subsystem, or system.
If the group has no execution rights for the designated object, the
No_Access exception is raised.
This function is intended for use in site-specific tools that manage CMVC
access control.
PARAMETERS
For_Group : String := "NETWORK_PUBLIC";
Specifies the group whose execution rights are to be returned. Only one
group can be named.
View_Or_Subsystem : String := "<CURSOR>";
Specifies the view, subsystem, or system for which the specified group's
execution rights are to be returned. Wildcards, context characters, and
attributes may be used, provided that the name resolves to a single view,
subsystem, or system. The default is the view, subsystem, or system
indicated by the cursor.
Response : String := "<WARN>";
Specifies how to respond to errors, how to generate logs, and what
activities and switches to use during the execution of this command. The
default is a profile that logs only warnings, errors, and exceptions.
return Execution_Table;
Returns the set of execution rights that have been granted to a group for
the designated view, subsystem, or system. If the group has no execution
rights for the designated object, the No_Access exception is raised.
REFERENCES
type Execution_Table
exception No_Access
@node !Commands.Cmvc_Access_Control.Group_Index
type Group_Index is range 0 .. 6;
DESCRIPTION
Defines a means of referencing the groups that have access to a particular
view, subsystem, or system.
When a group is assigned to an access class for a view, subsystem, or
system, the group name is recorded internally in an indexed list. Because
up to seven groups can have access to a view, subsystem, or system, the
index ranges from 0 through 6. The Group_Name function returns the name of
the group at the specific index in the list.
Group indexes are intended for use in site-specific tools that manage CMVC
access control. One possible use for indexes is to allow a tool to iterate
through the list of groups.
REFERENCES
function Group_Name
@node !Commands.Cmvc_Access_Control.Group_Name
function Group_Name
(The_Index : Group_Index := 0;
View_Or_Subsystem : String := "<CURSOR>";
Response : String := "<WARN>") return String;
DESCRIPTION
Returns the name of the group at the specified index for the designated
view, subsystem, or system.
When a group is assigned to an access class for a view, subsystem, or
system, the group name is recorded internally in an indexed list. The
list's index provides a means of referencing these groups, especially in
site-specific tools that manage CMVC access control. Such tools can iterate
through the indexes in a list of groups and use the Group_Name function to
convert each index into a group name.
Group names are indexed consecutively, starting with 0. If no group is at
the specified index, the function returns the null string (""). If an index
n is empty, then the index n+1 is also empty.
PARAMETERS
The_Index : Group_Index := 0;
Specifies the index for which to return a group name. This parameter
accepts an integer from 0 through 6.
View_Or_Subsystem : String := "<CURSOR>";
Specifies the view, subsystem, or system for which to return the indexed
group name. Wildcards, context characters, and attributes may be used,
provided that the name resolves to a single view, subsystem, or system.
The default is the view, subsystem, or system indicated by the cursor.
Response : String := "<WARN>";
Specifies how to respond to errors, how to generate logs, and what
activities and switches to use during the execution of this command. The
default is a profile that logs only warnings, errors, and exceptions.
return String;
Returns the name of the group at the specified index for the designated
view, subsystem, or system. If no group is at the specified index, the
function returns the null string ("").
REFERENCES
type Group_Index
@node !Commands.Cmvc_Access_Control.Has_Access
function Has_Access
(User_Or_Group : String := "<USER>";
In_Class : Access_Class := Cmvc_Access_Control.Reader;
View_Or_Subsystem : String := "<CURSOR>";
Group_Only : Boolean := False;
Response : String := "<WARN>") return Boolean;
DESCRIPTION
Returns true if the specified user or group belongs to the specified access
class (or to a more inclusive access class) for the designated view,
subsystem, or system.
If the User_Or_Group parameter specifies a group, that group is checked for
the specified access. If the User_Or_Group parameter specifies a username,
then all groups that include that username are checked for the specified
access.
When set to true, the Group_Only parameter causes the value of
User_Or_Group to be interpreted as a group name, even if a user exists
with the same name.
PARAMETERS
User_Or_Group : String := "<USER>";
Specifies the name of the user or group whose access is to be checked. Only
one name can be specified. The default special value "<USER>" specifies the
current user.
If a group is specified, the function checks whether the group belongs to
the specified access class for the designated view, subsystem, or system.
If a username is specified, the function checks whether any group
containing the user belongs to the desired access class. Note that the
interpretation of this parameter can be restricted by the Group_Only
parameter.
In_Class : Access_Class := Cmvc_Access_Control.Reader;
Specifies the access class in which to check the specified user's or group's
membership. One of four access classes can be specified - namely, Reader,
Client, Developer, or Owner. The default is the Reader access class.
View_Or_Subsystem : String := "<CURSOR>";
Specifies the view, subsystem, or system for which access is to be checked.
Multiple views, subsystems, or systems can be specified using wildcards,
context characters, set notation, indirect files, and attributes. The
default is the view, subsystem, or system indicated by the cursor.
Group_Only : Boolean := False;
Specifies whether the value of the User_Or_Group parameter is restricted to
group names. When false (the default), the User_Or_Group parameter can
name users or groups. When true, the value of the User_Or_Group parameter
is interpreted only as a group name, even if a user exists with the same
name.
Response : String := "<WARN>";
Specifies how to respond to errors, how to generate logs, and what
activities and switches to use during the execution of this command. The
default is a profile that logs only warnings, errors, and exceptions.
return Boolean;
Returns true if the specified user or group belongs to the specified access
class (or to a more inclusive access class) for the designated view,
subsystem, or system.
If the View_Or_Subsystem parameter names multiple objects, then this
function returns true only if the user or group has the specified access
for all of the named objects.
@node !Commands.Cmvc_Access_Control.Has_Right
function Has_Right
(User_Or_Group : String := "<USER>";
The_Right : Execution_Right := Cmvc_Access_Control.All_Rights;
View_Or_Subsystem : String := "<CURSOR>";
Group_Only : Boolean := False;
Response : String := "<WARN>") return Boolean;
DESCRIPTION
Returns true if the specified user or group has the specified execution
right for the designated view, subsystem, or system.
By default, this function checks whether all permitted rights have been
granted.
When the function is to check for all permitted rights, the User_Or_Group
parameter must specify a group name. If a username is specified, it is
interpreted as a group name.
When the function is to check for a single execution right, the
User_Or_Group parameter can specify either a username or a group name:
* If a username is specified, the function checks all groups containing
that username.
* If a group name is specified, the function checks only the specified
group.
The Group_Only parameter can be used to restrict the interpretation of the
User_Or_Group parameter, even when the function is to check for a single
execution right. When the value of the Group_Only parameter is true, the
User_Or_Group parameter is interpreted as a group name even if a user
exists with the same name.
PARAMETERS
User_Or_Group : String := "<USER>";
Specifies the name of the user or group whose execution rights are to be
checked. Only one name can be specified. The default special value "<USER>"
specifies the current user.
If the The_Rights parameter has its default value, or if the Group_Only
parameter is set to true, then the value of the User_Or_Group parameter is
interpreted as a group name, even if a user exists with the same name.
The_Right : Execution_Right := Cmvc_Access_Control.All_Rights;
Specifies the execution right for which to check. The possible execution
rights are listed under the Execution_Right type. By default, the function
checks whether all permitted rights have been granted. If the default
value is not used, only a single execution right can be specified.
View_Or_Subsystem : String := "<CURSOR>";
Specifies the view, subsystem, or system for which execution rights are to
be checked. Multiple views, subsystems, or systems can be specified using
wildcards, context characters, set notation, indirect files, and
attributes. The default is the view, subsystem, or system indicated by the
cursor.
Group_Only : Boolean := False;
Specifies whether the value of the User_Or_Group parameter is restricted to
group names. When false (the default), the User_Or_Group parameter can
name users or groups. When true, the value of the User_Or_Group parameter
is interpreted only as a group name, even if a user exists with the same
name. Note that if the The_Right parameter has its default value, the
User_Or_Group parameter is understood as a group name, regardless of the
value of the Group_Only parameter.
Response : String := "<WARN>";
Specifies how to respond to errors, how to generate logs, and what
activities and switches to use during the execution of this command. The
default is a profile that logs only warnings, errors, and exceptions.
return Boolean;
Returns true if the specified user or group has the specified execution
right for the designated view, subsystem, or system.
If the View_Or_Subsystem parameter names multiple objects, then this
function returns true only if the user or group has the specified rights
for all of the named objects.
@node !Commands.Cmvc_Access_Control.Initialize
procedure Initialize (View_Or_Subsystem : String := "<SELECTION>";
Response : String := "<PROFILE>");
DESCRIPTION
Initializes the specified view, subsystem, or system so that its access
control can be managed with operations in this package.
The Initialize command is useful primarily for setting up CMVC access
control in views, subsystems, or systems that were created under
previous releases of the Environment.
Initializing a view, subsystem, or system causes groups to be assigned to
CMVC access classes based on the access rights given in the object's
current ACL:
* All groups with owner access (O) are assigned to the Owner access class
for the view, subsystem, or system.
* All groups with read access (R) are assigned to the Reader access class
for the view, subsystem, or system. (This procedure ignores create (C)
and delete (D) access.)
Each group is granted all execution rights permitted by the access class
to which it was assigned.
The Initialize procedure also creates an object called Access_Control in
the State directory of the intialized view, subsystem, or system. This
object stores CMVC access-control information and causes CMVC commands to
check for appropriate access classes and execution rights.
If this procedure is applied to a view, subsystem, or system that is
already managed by CMVC access control, the effect is to reset the
access-control information to the initialized state. All groups currently
in the Owner access class remain in that class; all groups currently in
other access classes are assigned to the Reader access class.
PARAMETERS
View_Or_Subsystem : String := "<SELECTION>";
Specifies the view, subsystem, or system to be initialized. Multiple views,
subsystems, or systems can be specified using wildcards, context
characters, set notation, indirect files, and attributes. The default is
the highlighted view, subsystem, or system, provided that the highlight
contains the cursor.
Response : String := "<PROFILE>";
Specifies how to respond to errors, how to generate logs, and what
activities and switches to use during the execution of this command. The
default is the job response profile.
RESTRICTIONS
To initialize a view, you must have either Owner access to the view or
Owner access to the subsystem enclosing it.
To initialize a subsystem, you must have either Owner access to the
subsystem or the owner access right (O) to the world enclosing the
subsystem.
ERRORS
The Initialize command must obtain write locks on the objects whose ACLs
are to be set. This command will fail if it cannot obtain all of the
necessary write locks (for example, if someone is currently editing one of
the affected objects). As a result, the view, subsystem, or system is not
initialized and no ACLs are changed.
EXAMPLES
Assume that you have already initialized a subsystem and that you now want
to initialize all the views in it. You can do this by entering the
following command from the context of the subsystem:
Cmvc_Access_Control.Initialize
(View_Or_Subsystem => "@'c(spec_view,load_view,comb_view)");
@node !Commands.Cmvc_Access_Control.Is_Consistent
function Is_Consistent
(View_Or_Subsystem : String := "<CURSOR>";
Response : String := "<WARN>") return Boolean;
DESCRIPTION
Returns true if both of the following are true:
* Objects in the specified views, subsystems, or systems have access lists
(ACLs) that are consistent with the current CMVC access-class
assignments.
* The groups that have access to these views, subsystems, or systems
still exist.
When groups are assigned to CMVC access classes for views, subsystems, and
systems, ACLs for the individual objects are set. However, a user with
Owner access or operator capability can subsequently use operations in
packages Access_List and Access_List_Tools to reset the ACLs of individual
objects. Resetting individual ACLs can cause a group to have more or less
access than is warranted by its access class. The Is_Consistent function
can be used to query whether such operations have in fact been performed.
Similarly, a user with operator capability can delete a group after it has
been assigned to an CMVC access class. The Check procedure displays an
error message if it encounters a deleted group among access-class
assignments.
The Check procedure performs the same checks, optionally repairing any
inconsistent ACLs.
PARAMETERS
View_Or_Subsystem : String := "<CURSOR>";
Specifies one or more views, subsystems, or systems whose ACLs are to be
checked. Multiple views, subsystems, or systems can be specified using
wildcards, context characters, set notation, indirect files, and
attributes. The default is the view, subsystem, or system indicated by the
cursor.
Response : String := "<WARN>";
Specifies how to respond to errors, how to generate logs, and what
activities and switches to use during the execution of this command. The
default is a profile that logs only warnings, errors, and exceptions.
return Boolean;
Returns true if objects in the specified views, subsystems, or systems have
ACLs that are consistent with the current CMVC access-class assignments.
Returns false if inconsistent ACLs are found, if access-class assignments
reference deleted groups, if access-control information does not exist, or
if the current user does not have sufficient access to inspect the objects'
ACLs.
RESTRICTIONS
You must have Reader access to a view, subsystem, or system to query the
ACLs of objects in it.
REFERENCES
procedure Check
@node !Commands.Cmvc_Access_Control.Nil_Rights
Nil_Rights : constant Execution_Table := (others => False);
DESCRIPTION
Represents an execution table containing no execution rights.
Setting a group's execution rights to this constant prevents the group
from executing any CMVC commands for a given view, subsystem, or system.
REFERENCES
type Execution_Table
procedure Set_Rights
@node !Commands.Cmvc_Access_Control.No_Access
No_Access : exception;
DESCRIPTION
Is raised by the Get_Access or Get_Rights function to indicate that a
group has no access to the specified view, subsystem, or system.
REFERENCES
function Get_Access
function Get_Rights
@node !Commands.Cmvc_Access_Control.Remove_Group
procedure Remove_Group (The_Group : String := "<ALL>";
View_Or_Subsystem : String := "<SELECTION>";
Response : String := "<PROFILE>");
DESCRIPTION
Revokes the specified group's access to the designated view, subsystem, or
system.
This procedure removes the group from the access class to which it
belongs. By default, all groups with access to the specified view,
subsystem, or system are removed from their respective access classes.
Removing a group from an access class removes the group from the access
lists (ACLs) of the objects in the affected view, subsystem, or system.
Furthermore, the removed group loses all execution rights to the affected
view, subsystem, or system.
PARAMETERS
The_Group : String := "<ALL>";
Specifies the group whose access to the specified view, subsystem, or system
is to be revoked. The default special value "<ALL>" causes access to the
specified view, subsystem, or system to be revoked for all groups. If the
default value is not used, only a single group can be specified.
View_Or_Subsystem : String := "<SELECTION>";
Specifies the view, subsystem, or system for which the specified group's
access is to be revoked. Multiple views, subsystems, or systems can be
specified using wildcards, context characters, set notation, indirect files,
and attributes. The default is the highlighted view, subsystem, or system,
provided that the highlight contains the cursor.
Response : String := "<PROFILE>";
Specifies how to respond to errors, how to generate logs, and what
activities and switches to use during the execution of this command. The
default is the job response profile.
RESTRICTIONS
To remove a group from an access class for a view, you must have either
Owner access to the view or Owner access to the subsystem enclosing it.
To remove a group from an access class for a subsystem, you must have
either Owner access to the subsystem or the owner access right (O) to the
world enclosing the subsystem.
EXAMPLES
Assume that you want to remove all groups from all access classes for a
release called !Projects.Planetary_Motion.Demo.Rev1_0_1. You can do this
by selecting that release in the context of the Demo subsystem and then
entering the following command:
Cmvc_Access_Control.Remove_Group;
A message is displayed in the current output window listing the groups
whose access has been cleared. Now that no one has access to the release,
only an Owner of the enclosing subsystem can use the Add_Group command to
set new access-class assignments for it.
REFERENCES
type Access_Class
procedure Add_Group
@node !Commands.Cmvc_Access_Control.Remove_Right
procedure Remove_Right
(For_Group : String := "<ALL>";
The_Right : Execution_Right := Cmvc_Access_Control.All_Rights;
View_Or_Subsystem : String := "<SELECTION>";
Response : String := "<PROFILE>");
DESCRIPTION
Removes the specified execution right from the specified group for the
designated view, subsystem, or system.
By default, all groups lose all execution rights to the view, subsystem,
or system.
PARAMETERS
For_Group : String := "<ALL>";
Specifies the name of the group from which execution rights are to be
removed. The default special value "<ALL>" causes execution rights to be
removed from all groups that have access to the specified view, subsystem,
or system. If the default value is not used, only a single group name can
be specified.
The_Right : Execution_Right := Cmvc_Access_Control.All_Rights;
Specifies the execution right to be removed from the specified group. By
default, the procedure removes a group's entire set of execution rights
for the specified view, subsystem, or system. If the default value is not
used, only a single execution right can be specified.
View_Or_Subsystem : String := "<SELECTION>";
Specifies the view, subsystem, or system for which an execution right is to
be removed. Multiple views, subsystems, or systems can be specified using
wildcards, context characters, set notation, indirect files, and
attributes. The default is the highlighted view, subsystem, or system,
provided that the highlight contains the cursor.
Response : String := "<PROFILE>";
Specifies how to respond to errors, how to generate logs, and what
activities and switches to use during the execution of this command. The
default is the job response profile.
RESTRICTIONS
To revoke an execution right for a view, you must have Owner access to the
view.
To revoke an execution right for a subsystem, you must have Owner access
to the subsystem.
EXAMPLES
Assume that a group called Tom has Developer access to a view, and you
want to revoke all but three of the group's execution rights to that view.
To do this:
1. Select the view and enter the following command to remove the entire
set of execution rights to that view:
Cmvc_Access_Control.Remove_Right (For_Group => "Tom");
2. Use the Add_Right command to restore each of the desired execution
rights.
REFERENCES
procedure Add_Right
@node !Commands.Cmvc_Access_Control.Set_Rights
procedure Set_Rights
(For_Group : String := "NETWORK_PUBLIC";
The_Rights : Execution_Table := Cmvc_Access_Control.Nil_Rights;
View_Or_Subsystem : String := "<SELECTION>";
Response : String := "<PROFILE>");
DESCRIPTION
Grants the specified set of execution rights to the specified group for the
designated view, subsystem, or system.
Within the specified set of execution rights, individual rights can be set
only if they are permitted by the group's access class. Warning messages
are produced for inappropriate rights.
This procedure is intended for use in site-specific tools that manage CMVC
access control. Note that a group can be granted the entire set of
permitted execution rights when it is added to an access class (see the
Add_Group command). Furthermore, the Add_Right procedure can be used to
set individual execution rights interactively.
PARAMETERS
For_Group : String := "NETWORK_PUBLIC";
Specifies the group to which execution rights are to be granted. Only one
group can be named.
The_Rights : Execution_Table := Cmvc_Access_Control.Nil_Rights;
Specifies the execution table containing the set of execution rights to be
granted. By default, no rights are set, so that the specified group cannot
apply any CMVC commands to the specified view, subsystem, or system.
View_Or_Subsystem : String := "<SELECTION>";
Specifies the view, subsystem, or system for which execution rights are to
be granted. Multiple views, subsystems, or systems can be specified using
wildcards, context characters, set notation, indirect files, and
attributes. The default is the highlighted view, subsystem, or system,
provided that the highlight contains the cursor.
Response : String := "<PROFILE>";
Specifies how to respond to errors, how to generate logs, and what
activities and switches to use during the execution of this command. The
default is the job response profile.
RESTRICTIONS
To grant a set of execution rights for a view, you must have Owner access
to the view.
To grant a set of execution rights for a subsystem, you must have Owner
access to the subsystem.
REFERENCES
type Execution_Table
@node !Commands.Cmvc_Access_Control.Subsystem_Client_Rights
Subsystem_Client_Rights : constant Execution_Table :=
Execution_Table'(Add_Child_Child => True, others => False)
or Subsystem_Reader_Rights;
DESCRIPTION
Represents the set of subsystem and system execution rights that can be
granted to groups with Client access to the subsystem (or system).
REFERENCES
type Execution_Table
constant Subsystem_Developer_Rights
constant Subsystem_Owner_Rights
constant Subsystem_Reader_Rights
@node !Commands.Cmvc_Access_Control.Subsystem_Client_View_Rights
Subsystem_Client_View_Rights : constant Execution_Table :=
Subsystem_Reader_View_Rights;
DESCRIPTION
Represents the set of view execution rights that can be granted to groups
with Client access to the subsystem (or system) enclosing the view.
REFERENCES
type Execution_Table
constant Subsystem_Developer_View_Rights
constant Subsystem_Owner_View_Rights
constant Subsystem_Reader_View_Rights
@node !Commands.Cmvc_Access_Control.Subsystem_Developer_Rights
Subsystem_Developer_Rights : constant Execution_Table :=
Execution_Table'(Edit_Notes => True,
Add_Child_Parent => True,
Remove_Child => True,
Update_Cdb => True,
others => False)
or Subsystem_Client_Rights;
DESCRIPTION
Represents the set of subsystem and system execution rights that can be
granted to groups with Developer access to the subsystem (or system).
REFERENCES
type Execution_Table
constant Subsystem_Client_Rights
constant Subsystem_Owner_Rights
constant Subsystem_Reader_Rights
@node !Commands.Cmvc_Access_Control.Subsystem_Developer_View_Rights
Subsystem_Developer_View_Rights : constant Execution_Table :=
Execution_Table'(Check_Out => True,
Check_In => True,
Accept_Changes_Source => True,
Accept_Changes_Destination => True,
Abandon_Reservation => True,
Revert => True,
Modify_Notes => True,
Make_Controlled => True,
Make_Uncontrolled => True,
Sever => True,
Join_What => True,
Join_To => True,
Merge_Changes_Destination => True,
Merge_Changes_Source => True,
others => False)
or Subsystem_Client_View_Rights;
DESCRIPTION
Represents the set of view execution rights that can be granted to groups
with Developer access to the subsystem (or system) enclosing the view.
REFERENCES
type Execution_Table
constant Subsystem_Client_View_Rights
constant Subsystem_Owner_View_Rights
constant Subsystem_Reader_View_Rights
@node !Commands.Cmvc_Access_Control.Subsystem_Owner_Rights
Subsystem_Owner_Rights : constant Execution_Table :=
Execution_Table'(Initial => True,
Destroy_Config => True,
Destroy_Subsystem => True,
Build => True,
Subsystem_Check_Consistency => True,
Expunge_Database => True,
Make_Primary => True,
Make_Secondary => True,
Destroy_Cdb => True,
others => False)
or Subsystem_Developer_Rights;
DESCRIPTION
Represents the set of subsystem and system execution rights that can be
granted to groups with Owner access to the subsystem (or system).
REFERENCES
type Execution_Table
constant Subsystem_Client_Rights
constant Subsystem_Developer_Rights
constant Subsystem_Reader_Rights
@node !Commands.Cmvc_Access_Control.Subsystem_Owner_View_Rights
Subsystem_Owner_View_Rights : constant Execution_Table :=
Execution_Table'(Release => True,
Copy => True,
Make_Path => True,
Make_Subpath => True,
Make_Spec_View => True,
Make_Code_View => True,
Destroy_View => True,
Check_Consistency => True,
others => False)
or Subsystem_Developer_View_Rights;
DESCRIPTION
Represents the set of view execution rights that can be granted to groups
with Owner access to the subsystem (or system) enclosing the view.
REFERENCES
type Execution_Table
constant Subsystem_Client_View_Rights
constant Subsystem_Developer_View_Rights
constant Subsystem_Reader_View_Rights
@node !Commands.Cmvc_Access_Control.Subsystem_Reader_Rights
Subsystem_Reader_Rights : constant Execution_Table :=
Execution_Table'(Query_Subsystem => True, others => False);
DESCRIPTION
Represents the set of subsystem and system execution rights that can be
granted to groups with Reader access to the subsystem (or system).
REFERENCES
type Execution_Table
constant Subsystem_Client_Rights
constant Subsystem_Developer_Rights
constant Subsystem_Owner_Rights
@node !Commands.Cmvc_Access_Control.Subsystem_Reader_View_Rights
Subsystem_Reader_View_Rights : constant Execution_Table :=
Execution_Table'(Import_From => True,
Import_Into => True,
Remove_Import => True,
Replace_Model => True,
Query_View => True,
Build_Activity_In => True,
Build_Activity_From => True,
Expand_Activity => True,
others => False);
DESCRIPTION
Represents the set of view execution rights that can be granted to groups
with Reader access to the subsystem (or system) enclosing the view.
REFERENCES
type Execution_Table
constant Subsystem_Client_View_Rights
constant Subsystem_Developer_View_Rights
constant Subsystem_Owner_View_Rights
@node !Commands.Cmvc_Access_Control.View_Client_Rights
View_Client_Rights : constant Execution_Table :=
Execution_Table' (Import_From => True,
Build_Activity_From => True,
others => False)
or View_Reader_Rights;
DESCRIPTION
Represents the set of view execution rights that can be granted to groups
with Client access to the view.
REFERENCES
type Execution_Table
constant View_Developer_Rights
constant View_Owner_Rights
constant View_Reader_Rights
@node !Commands.Cmvc_Access_Control.View_Developer_Rights
View_Developer_Rights : constant Execution_Table :=
Execution_Table'(Check_Out => True,
Check_In => True,
Accept_Changes_Destination => True,
Abandon_Reservation => True,
Revert => True,
Modify_Notes => True,
Make_Controlled => True,
Make_Uncontrolled => True,
Sever => True,
Join_What => True,
Release => True,
Make_Path => True,
Make_Subpath => True,
Make_Code_View => True,
Copy => True,
Make_Spec_View => True,
Merge_Changes_Destination => True,
Build_Activity_In => True,
others => False)
or View_Client_Rights;
DESCRIPTION
Represents the set of view execution rights that can be granted to groups
with Developer access to the view.
REFERENCES
type Execution_Table
constant View_Client_Rights
constant View_Owner_Rights
constant View_Reader_Rights
@node !Commands.Cmvc_Access_Control.View_Owner_Rights
View_Owner_Rights : constant Execution_Table :=
Execution_Table'(Import_Into => True,
Remove_Import => True,
Replace_Model => True,
Destroy_View => True,
Check_Consistency => True,
others => False)
or View_Developer_Rights;
DESCRIPTION
Represents the set of view execution rights that can be granted to groups
with Owner access to the view.
REFERENCES
type Execution_Table
constant View_Client_Rights
constant View_Developer_Rights
constant View_Reader_Rights
@node !Commands.Cmvc_Access_Control.View_Reader_Rights
View_Reader_Rights : constant Execution_Table :=
Execution_Table'(Accept_Changes_Source => True,
Join_To => True,
Merge_Changes_Source => True,
Query_View => True,
Expand_Activity => True,
others => False);
DESCRIPTION
Represents the set of view execution rights that can be granted to groups
with Reader access to the view.
REFERENCES
type Execution_Table
constant View_Client_Rights
constant View_Developer_Rights
constant View_Owner_Rights