| Oracle® Beehive Administrator's Guide Release 1 (1.4) Part Number E13797-02 |
|
|
View PDF |
| Oracle® Beehive Administrator's Guide Release 1 (1.4) Part Number E13797-02 |
|
|
View PDF |
Oracle Beehive uses a robust and highly-configurable model for controlling access to the various features of Oracle Beehive, and to the shared content stored by users, including files, folders, workspaces, calendars, and so forth.
During installation, a default setup is created providing a variety of pre-configured privileges, roles, and sensitivities. (Each of these special terms is defined in detail in the first section of this module.)
This module describes the various functions you can use, as an administrator, to customize how Oracle Beehive grants and limits access for your users. It contains the following topics:
In Release 1 of Oracle Beehive, you can use the beectlbeectlbeectl list_commands
beectl> list_commands --category "access control"
In Oracle Beehive, there are two methods for controlling access to objects:
Explicit Access Control: Access Control applied directly to controllable objects
Implicit Access Control: Permissions granted or denied from users and groups
Explicit access control is accomplished by creating "Access Control Entities (ACEs)", which are logical pairings of "Accessors" and "Access Privileges". An ACE may either grant or restrict any of five Access Types:
READ: coded as +R or -R, this access type grants or revokes permission to open or read the object
WRITE: coded as +W or -W, this access type grants or revokes permission to add, alter, or make changes to the object. Note that version control preserves previous versions, so WRITE access does not itself provide DELETE access
DISCOVER: coded as +O or -O, this access type grants or revokes permission to see the object in lists, look it up in directories, find it in searches, and so forth. When DISCOVER privileges are revoked, a user cannot detect the existence of that object using any Oracle Beehive client process
EXECUTE: coded as +E or -E, this access type grants or revokes permission to invoke or assign the object or cause it to perform its function
DELETE: coded as +D or -D, this access type grants or revokes permission to delete the object
Note:
Not all access types have meaning for all entity types. For example, "delete" access is meaningless in the context of access to a service; "execute" access is meaningless in the context of access to a text file. Oracle Beehive ignores access type settings that are meaningless in a given context.In an ACE, access types are referenced as +-RWOED (for example, "RW-D", or "–D+RW").
Any Oracle Beehive object may have any number of ACEs, collected into an Access Control List (ACL). ACLs are simply tables of ACEs, all of which apply to a single controllable entity.
You may find that you need to grant a similar collection of ACEs repeatedly to various different objects. To facilitate this, Oracle Beehive provides Sensitivities. A sensitivity is simply an ACL, given a label, and made available for users to apply to any object. A sensitivity on its own is not yet active; users apply sensitivities to entities, and thereby create an ACL containing the ACEs encapsulated by the sensitivity.
Sensitivities are always created at the workspace level of scope. A workspace manager can view or search for sensitivities within the workspace, using a client application.
For example, a ÒConfidentialÓ sensitivity could be applied to a set of artifacts. This sensitivity would prevent access from ALL_USERS, but grant access only to the creator of the object. Later, an instruction like Òshare all Confidential documents with BobÓ can be used by a workspace manager, to alter the sensitivity (and thus all objects in the workspace having that sensitivity) to grant Bob READ access to them.
Implicit access control is accomplished by granting or revoking various levels of access (privileges) to users. You may do this by applying privileges directly to user accounts, or to any container which contains user accounts (groups, organizations, or the enterprise).
Oracle Beehive includes about 47 pre-defined privileges. Privileges are used to define access when there is no relevant entity. Examples include EMAIL_USER, AUDITOR, and WORKSPACE_MGR. The EMAIL_USER privilege grants access to use the E-mail functionality in Oracle Beehive. The AUDITOR privilege grants access to Oracle Beehive auditing functionality. You can list all privileges using the beectl list_privileges
The easiest and most flexible way to manage implicit access control is through the use of Roles.
A role is similar to a sensitivity; it encapsulates a collection of granted and revoked privileges, under a single label. However, you assign roles to users, thereby granting those users implicit access. Oracle Beehive is packaged with default roles, which you may modify, and you can also create new roles to meet the requirements of your organization.
A privilege is an assignable entity that grants access to some part of Oracle Beehive. For example, the EMAIL_USER privilege grants access to Oracle Beehive e-mail functions. Table 13-1, "Default Oracle Beehive Privileges" lists the default privileges pre-defined in every Oracle Beehive deployment.
Table 13-1 Default Oracle Beehive Privileges
| Privilege | Access Granted |
|---|---|
|
ARCHIVE_MGR |
Business administrator access to archiving functionality |
|
AUDITOR |
Access to read auditing logs |
|
AUDIT_ADMIN |
Allows assignee to configure audit policy |
|
BYPASS |
Global superuser privilege allows assignee to perform any possible function |
|
CALENDAR_MGR |
Business administrator access to time management functionality |
|
CALENDAR_USER |
User-level access to the calendar functionality |
|
CONF_MGR |
Business administrator access to web conferencing |
|
CONF_USER |
User-level access to the web conferencing functionalityFootref 1 |
|
CONTENT_MGR |
Business administrator access to file management |
|
CONTENT_USER |
User-level access to the file management functionality within workspacesFootref 1 |
|
DELEGATE |
|
|
DIAGNOSE |
|
|
DM_MGR |
Business administrator access to mobile device management functionality |
|
EMAIL_MGR |
Business administrator access to e-mail settings |
|
EMAIL_USER |
User-level access to the e-mail functionality |
|
EXCEED_QUOTA |
|
|
FORUM_MGR |
Administrator access to discussions functionality |
|
FORUM_USER |
User-level access to the discussions functionalityFootref 1 |
|
IM_MGR |
Business administrator access to instant messaging functionality |
|
IM_USER |
User-level access to the instant messaging functionalityFootref 1 |
|
LOGIN |
|
|
MARKER_MGR |
|
|
MODIFY_ACL |
System administrator access to add to, or modify, access control lists on objects |
|
NOTIFICATION_MGR |
Administrator access to notifications functionality |
|
NOTIFICATION_USER |
User-level access to the notifications functionality |
|
ORGANIZATION_MGR |
Administrator access to |
|
POLICY_MGR |
Administrator access to policies |
|
PREFERENCE_MGR |
Administrator access to setting default preferences |
|
PROTOCOL_USER |
User-level access to WebDAV and FTP protocolsFoot 1 |
|
QUOTA_MGR |
Administrator access to quota settings within the specified scope |
|
READALL |
|
|
RESOURCE_MGR |
Administrator access to resource management |
|
ROLE_MGR |
Allows access to assign roles, within a specified scope |
|
SECURITY |
|
|
SUBSCRIPTION_MGR |
Administrator access to subscriptions functionality |
|
SUBSCRIPTION_USER |
User-level access to the subscription functionality |
|
SYSTEM_OPER |
|
|
TASK_MGR |
Administrator access to tasks functionality |
|
TASK_USER |
User-level access to the tasks functionalityFootref 1 |
|
TIMEZONE_MGR |
Administrator access to managing time zones |
|
USER_MGR |
Administrator access to managing users |
|
VERSION_MGR |
|
|
VOICE_USER |
User-level access to the voice messaging functionalityFootref 1 |
|
WEBADMIN_USER |
Allows access to Oracle Beehive Administration Console (Oracle Beekeeper). This privilege is only available in Oracle Beehive version 1.3 or later |
|
WORKFLOWTASK_MGR |
Administrator access to assigning and managing workflow tasks |
|
WORKFLOW_MGR |
Administrator access to workflow functionality |
|
WORKSPACE_ADD |
Allows assignee to add workspaces within the specified scope |
|
WORKSPACE_MGR |
Administrator access within the specified workspace scope |
Footnote 1 In Oracle Beehive Release 1, this privilege is inactive, meaning, the granted access is always available regardless of assignment of this privilege. The ability to disable this level of access by revoking this privilege is planned for a future release of Oracle Beehive.
A role is a collection of privileges, which can be assigned to users. Roles are convenient because they allow you to provide several different layers of privileges to a heterogeneous population of users. A user may have any number of roles, granting the appropriate collection of privileges at a variety of scopes.
Note:
"Scope" refers to a logical level of organization within the Oracle Beehive deployment; the enterprise, or a specific organization, or a specific workspace.An assigned role has two parts:
An Assignee (a user or group)
A Role Definition - Encapsulates access types and privileges for a given scope. It has no effect until assigned
This section includes the following topics:
As part of the initial install seeding, a collection of role definitions are created and assigned (through assigned roles) to the ALL_USERS dynamic group (which is also seeded at install time). This means that all users within your enterprise are eligible to be assigned any of the default roles. Additional default role definitions are available, but unassigned.
When you create custom role definitions, you can assign them to specific groups, and at scopes lower than the enterprise level, if you wish.
You can list the existing role definitions using the beectl list_role_definitions
beectl> list_role_definitions
This produces output similar to the following:
------------------------------------------------------------------------------------------------------------------------------------------- | role_definition | name | description | access_types | privileges | always_enabled | ------------------------------------------------------------------------------------------------------------------------------------------- | acrd=AUDIT-ADMIN,enpr=mycompany | AUDIT-ADMIN | | | [AUDIT_ADMIN] | true | | acrd=AUDITOR,enpr=mycompany | AUDITOR | | | [AUDITOR] | true | | acrd=DEFAULT_RESOURCE_ROLE_DEFINITION,enpr=mycompany | DEFAULT_RESOURCE_ROLE_DEFINITION | ResourceMgrRoleDef | | [CALENDAR_USER, TASK_USER] | true | | acrd=DELEGATOR,enpr=mycompany | DELEGATOR | | | [DELEGATE] | true | | acrd=enterprise-administrator,enpr=mycompany | enterprise-administrator | | | [ARCHIVE_MGR, EXCEED_QUOTA, MARKER_MGR, ORGANIZATION_MGR, PREFERENCE_MGR, QUOTA_MGR, ROLE_MGR, USER_MGR, VERSION_MGR, WORKSPACE_MGR] | true | | acrd=enterprise-system,enpr=mycompany | enterprise-system | enterprise-system | | [BYPASS] | true | | acrd=user-calendar,enpr=mycompany | user-calendar | | | [CALENDAR_USER] | true | | acrd=user-content,enpr=mycompany | user-content | | | [CONTENT_USER] | true | | acrd=user-core,enpr=mycompany | user-core | | | [LOGIN, PROTOCOL_USER, WORKSPACE_ADD] | true | | acrd=user-discussions,enpr=mycompany | user-discussions | | | [FORUM_USER] | true | | acrd=user-email,enpr=mycompany | user-email | | | [EMAIL_USER] | true | | acrd=user-notification,enpr=mycompany | user-notification | | | [NOTIFICATION_USER] | true | | acrd=user-subscription,enpr=mycompany | user-subscription | | | [SUBSCRIPTION_USER] | true | | acrd=user-task,enpr=mycompany | user-task | | | [TASK_USER] | true | | acrd=workspace-coordinator,enpr=mycompany | workspace-coordinator | | +RWDEO | [CALENDAR_MGR, CONF_MGR, CONTENT_MGR, EMAIL_MGR, FORUM_MGR, IM_MGR, MARKER_MGR, MODIFY_ACL, NOTIFICATION_MGR, POLICY_MGR, PREFERENCE_MGR, READALL, ROLE_MGR, SECURITY, SUBSCRIPTION_MGR, USER_MGR, VERSION_MGR, WORKFLOW_MGR, WORKSPACE_MGR] | true | | acrd=workspace-document-coordinator,enpr=mycompany | workspace-document-coordinator | | +RWDEO | [CONTENT_MGR, FORUM_MGR, MARKER_MGR, MODIFY_ACL, VERSION_MGR, WORKFLOW_MGR] | true | | acrd=workspace-member,enpr=mycompany | workspace-member | | +RWDEO | | true | | acrd=workspace-participant-coordinator,enpr=mycompany | workspace-participant-coordinator | | +RO | [MODIFY_ACL, ROLE_MGR, USER_MGR] | true | | acrd=workspace-viewer,enpr=mycompany | workspace-viewer | | +RO | | true | -------------------------------------------------------------------------------------------------------------------------------------------
As an example, the role definition user-email has the privilege EMAIL-USER granted to it. Similarly, the workspace-viewer role definition has access types +RO (it allows READ and DISCOVER access) granted to it.
You can use the beectl list_role_definitions% wildcard. For example, to find all role definitions related to workspaces, issue the following command:
beectl> list_role_definitions --name workspa%
This command should return results including: workspace-participant-coordinator, workspace-viewer, workspace-member, workspace-document-coordinator, and workspace-coordinator.
A role definition is simply a collection of privileges and access types. While Oracle Beehive comes pre-seeded with a variety of default role definitions, you may find it convenient to create your own role definitions.
To create a custom role definition, use the beectl add_role_definition
Note:
For some privileges, scope does not make sense or is not required. For example, the LOGIN privilege allows or disallows user authentication with Oracle Beehive. Users do not log in at a level of scope, so a definition of scope makes no sense in combination with the LOGIN privilege.For privileges that do take a scope, if you do not specify a scope, scope is set to the enterprise level by default.
For example:
beectl> add_role_definition --scope orgn=human_resources,enpr=mycompany --name hr-administrator --description "A manager of users and roles" --privilege ROLE_MGR --privilege USER_MGR --access_types ORWDE --always_enabled true
In this example, two privileges are granted: ROLE_MGR and USER_MGR. Additionally, all access types are granted. This role might be appropriate for a high-level administrator needing access to all objects in the organization, and the ability to grant roles to all users within that organization. Alternatively, if the scope were set at the level of a workspace, it might be useful for a director or manager needing access to manage users and assign roles only within that workspace. Note that in order to assign roles, a user must have the ROLE_MGR privilege, and in order to assign them to users, the USER_MGR privilege is needed.
As another example:
beectl> add_role_definition --scope enpr=mycompany --name workspace-viewer --description "Can see everything in the workspace" --access_types OR --always_enabled true
In this example, the role definition grants blanket Discover and Read access within the context in which it is assigned. This might be useful as a guest role, assignable at the level of a workspace, which would allow a guest user to find and read, but not modify, objects within the scope specified. This role definition is also set to "always enabled". This affects how the role definition works when it is used in an assigned role. See "Creating Assigned Roles" for details.
This role definition example actually recreates one of the default role definitions provided in Oracle Beehive: the workspace-viewer role.
Notes:
To see a list of all privileges, use the
beectl list_privilegesIn Oracle Beehive, the convention is that all role definitions are in all-lowercase, while privileges are in all-caps. If you follow this convention when creating role definitions, you may find it easier to distinguish them from privileges when constructing your commands.
Exposing a Role Definition to Users
Once you have created a role definition, you have the option of creating an ACE which will expose the role definition to users. If you do not take this step, the role definition will only be manageable from the command-line. Users within Oracle Beehive will not be able to see, or make use of, the custom role.
To expose a role definition, add an ACE using the beectl add_local_ace
beectl> add_local_ace --entity acrd=workspace-viewer,enpr=mycompany --accessor grup=ADMINS,enpr=mycompany --access_types RE
This command grants Read and Execute access types, enabling the members of the ADMINS group to execute (assign) the role definition specified in <Role>. Note that the entity is defined by listing the role definition by name, the organization by name, and the enterprise by name, separated by commas (no spaces). The accessor is specified by name, using the same fully-qualified syntax.
All access control role definitions have the four-letter code acrd, organizations are orgn, and enterprises are enpr.
You may tie a role definition to an object called an Assigned Role. Assigned roles grant role definitions directly to users or groups. An assigned role always specifies assignees, and may also specify scope.
An Assigned role ties a role definition to a set of accessors in a given scope.
If the role definition that is associated with the assigned role is marked "Always Enabled", then the assigned role is always enabled for all of its accessors; it may not be disabled. If the role definition is not marked "Always Enabled", then by default it is disabled for all of its accessors unless and until it is enabled (by a user).
Note that if an assigned role is disabled (that is, its role definition is not marked "Always Enabled", and it has not been enabled in the current user context), privileges and access types that are specified in the role definition have no effect. However, if the role definition denies any access types, those denied access types still take effect.
For example, to assign the workspace-viewer role to a user, with the scope of a workspace (so the role definition applies for that user to that specific workspace only), use the beectl add_assigned_role
beectl> add_assigned_role --scope enpr=mycompany --name my_assigned_role --assigned_scope wksp=myworkspace,orgn=human_resources,enpr=mycompany --role_definition acrd=workspace-viewer,enpr=mycompany --accessor <USERID>
Provide the identifier of the user for <USERID>.
Note that some users have privileges allowing them to assign roles (such as the ROLE_MGR privilege). Whenever a user assigns a role definition to another user, they are effectively creating an assigned role. If the user can see (discover) and assign (execute) permissions for a role definition, they can assign it to other users for which they have management privileges (such as USER_MGR).
You can modify any role definition by using the beectl modify_role_definition
beectl> modify_role_definition --role_definition <role_definition_id> [--name<name>] [--description <description>] [[--privilege <privilege_name>]...][--access_types <access_types_string>] [--always_enabled <boolean_value>]
Only use options for parts of the role definition you wish to change. For example, if you only wish to change the name, identify the role definition using the --role_definition and its identifier, and then use the --name option to specify a new name.
You can change the assignee(s) of any assigned role, adding or removing accessors, using the beectl modify_assigned_role
beectl> modify_assigned_role --assigned_role <assigned_role_id> [--name <name>] [--description <description>] [--assigned_scope <assigned_scope_id>] [--role_definition <role_definition_id>] [[--add_accessor <accessor_id>]...] [[--remove_accessor <accessor_id>]...]
Use the --add_accessor and --remove_accessor options to list accessors from whom you want to grant or revoke the assigned role.
You can delete roles using the beectl delete_assigned_role
beectl> delete_assigned_role --assigned_role <assigned_role_id>
When you delete an assigned role, you are effectively removing it from all assignees. This changes the privileges for all affected users, so caution is advised.
You can also delete a role definition, using the beectl delete_role_definition
beectl> delete_role_definition --role_definition <role_definition_id>
Note:
If you attempt to delete a role definition that is currently assigned, Oracle Beehive will return an error. You must unassign the role definition from all actors in the system before you can delete it.This section describes how to create and manage ACEs and sensitivities.
Any Oracle Beehive object may have any number of ACEs, collected into an Access Control List (ACL). ACLs are simply tables of ACEs, all of which apply to a single controllable entity. You never need to "create" an ACL: creating an ACE on any object automatically creates an ACL for it. If an object has one or more ACEs, it has an ACL, and if all ACEs are removed from an object, it no longer has an ACL. Oracle Beehive manages this task for you. All you need to do is create, modify, and delete ACEs according to your needs.
Sensitivities are just like ACLs, except that they are not attached to an object. Instead, a sensitivity is an ACL-template, which may be used again and again to assign the same ACL to many different objects.
This section contains the following topics:
You can create an ACE for most types of entities in Oracle Beehive.
Each ACE contains three values: the entity, which specifies where the ACE will be applied (a workspace, folder, calendar, etc.); the accessor, which specifies for whom this ACE applies (a user, members of a specified group, etc.); and a string defining access types ( +-RWOED ).
This section contains the following topics:
To view the ACL of an object (listing all ACEs currently applied to it), use the beectl list_local_acl
beectl> list_local_acl --entity <entity_id>
Specify the entity using its identifier. Each ACE is listed, including its accessor and access type list.
To create a new ACE (adding it to the ACL of an existing entity), use the beectl add_local_ace
beectl add_local_ace --entity <entity_id> --accessor <accessor_id> [--access_types <access_types_string>]
An ACL may only have a single ACE for each accessor. If an ACE for an accessor already exists, you must modify it to alter the access types, by modifying the ACE.
To modify an existing ACE, use the beectl modify_local_ace
beectl> modify_local_ace --entity <entity_id> --accessor <accessor_id> [--access_types <access_types_string>]
Specify both the entity and the accessor, using their identifiers, to identify the ACE you wish to edit. The access type string you provide will replace the current access type string of the specified ACE.
To delete an ACE, use the beectl delete_local_ace
beectl> delete_local_ace --entity <entity_id> --accessor <accessor_id>
Specify both the entity and the accessor, using their identifiers, to identify the ACE you wish to delete.
A sensitivity is a template ACL, containing ACEs. Users can assign sensitivities repeatedly to different objects, saving the effort of having to create the same ACEs again and again. A sensitivity also exposes the ability to set access control at the object level (explicit access control) to privileged users who do not have access to the command line.
Note:
Sensitivities are always created and managed at the workspace level of scope.This section contains the following topics:
To see a list of all sensitivities available in a workspace, first, get the workspace's unique identifier by using the beectl list_workspaces
beectl> list_workspaces --scope enpr=Example --type p
This produces output similar to the following:
---------------------------------------------------------------------- | Workspace Name | Workspace Type | Identifier | ---------------------------------------------------------------------- | SystemWorkspace | PERSONAL | wksp=SystemWorkspace,enpr=mycompany| | beeadmin's Personal Workspace | PERSONAL | wksp=beeadmin's Personal Workspace,enpr=mycompany | | example.user's Personal Workspace | PERSONAL | wksp=example.user's Personal Workspace,enpr=mycompany | ----------------------------------------------------------------------
To list the sensitivities in a workspace, use the beectl list_sensitivities
beectl> list_sensitivities --workspace "wksp=example.user's Personal Workspace,enpr=mycompany"
This produces output similar to the following:
-------------------------------------------------------------------------------------------------------------------- | sensitivity | name | description | sensitivity_only | delegatable | -------------------------------------------------------------------------------------------------------------------- | acsn=Confidential,wksp=example.user's Personal Workspace,enpr=mycompany | Confidential | confidential sensitivity | false | true | | acsn=Normal,wksp=example.user's Personal Workspace,enpr=mycompany | Normal | normal sensitivity | false | true | | acsn=Private,wksp=example.user's Personal Workspace,enpr=mycompany | Private | private sensitivity | true | false | | acsn=Public,wksp=example.user's Personal Workspace,enpr=mycompany | Public | public sensitivity | false | true | --------------------------------------------------------------------------------------------------------------------
You can use the --name command to search for only sensitivities matching the provided string. Use the % symbol as a wildcard.
To review the ACL (all ACEs) of a specific sensitivity, use the beectl list_sensitivity_acl
beectl> list_sensitivity_acl --sensitivity " acsn=Public,wksp=example.user's Personal Workspace,enpr=mycompany"
This produces output similar to the following:
----------------------------------------------- | accessor | access_types | ----------------------------------------------- | grup=ALL_USERS,enpr=mycompany | +RO | ----------------------------------------------- Listed SensitivityACL for Sensitivity 'acsn=Confidential,wksp=example.user's Personal Workspace,enpr=mycompany'
As you can see, the default personal workspace contains a default sensitivity called "Public". This sensitivity grants Read and Discover access to the members of the ALL_USERS group, which contains all users in the enterprise. Therefore, this sensitivity allows any other Oracle Beehive user to discover and read (but not modify or delete) items in the workspace marked with this sensitivity.
To create a new sensitivity, use the beectl add_sensitivity
beectl> add_sensitivity --workspace <workspace_id> --name <name> [--description <description>] [--sensitivity_only <boolean_value>] [--delegatable <boolean_value>]
Specify the workspace scope using the --workspace option, and give the sensitivity a unique name using --name. Optionally, you can give the sensitivity a description, using the --description option; the description will be readable by users when they are choosing and assigning sensitivities.
To create a new sensitivity ACE, use the beectl add_sensitivity_ace
beectl> add_sensitivity_ace --sensitivity <entity_id> --accessor <accessor_id> [--access_types <access_types_string>]
Specify the sensitivity using its identifier. As with normal ACEs, sensitivity ACEs combine an accessor with an access type string. You may only have one ACE in a given ACL with the same accessor. You can use the beectl modify_sensitivity_ace
For more details on ACEs, see "Creating and Managing ACEs".
To modify an existing sensitivity, use the beectl modify_sensitivity
beectl> modify_sensitivity --sensitivity <sensitivity_id> [--name <name>] [--description <description>] [--sensitivity_only <boolean_value>] [--delegatable <boolean_value>]
Specify the sensitivity using its identifier. Note that you add, modify, and remove ACEs from a sensitivity using the beectl add_sensitivity_acebeectl modify_sensitivity_acebeectl delete_sensitivity_ace
To modify an existing sensitivity ACE, use the beectl modify_sensitivity_ace
beectl> modify_sensitivity_ace --sensitivity <entity_id> --accessor <accessor_id> [--access_types <access_types_string>]
This command effectively replaces an existing sensitivity ACE with the new one you specify, based on the --accessor. Hence, you must specify both the sensitivity identifier and the accessor, and then optionally provide a new access type string.
To delete a sensitivity ACE, use the beectl delete_sensitivity_ace
beectl> delete_sensitivity_ace --sensitivity <sensitivity_id> --accessor <accessor_id>
Specify the sensitivity using its identifier, and specify the accessor. The ACE corresponding to the accessor you identify will be removed.
To delete a sensitivity, use the beectl delete_sensitivity
beectl> delete_sensitivity --sensitivity <sensitivity_id>
Specify the identifier of the sensitivity you wish to delete.
Note:
If a sensitivity is currently assigned to any objects in its workspace, Oracle Beehive will return an error message when you attempt to delete it. You must unassign the sensitivity from all objects before it can be deleted.
|
 Copyright © 2008, Oracle. All rights reserved. Legal Notices |
|