Access to composite applications and components

 

+

Search Tips   |   Advanced Search

 

Specify user access to composite applications, application pages, and application components by customizing the default membership roles that are initially displayed in the Roles portlet.

Use the Roles portlet to view, create, edit, and delete the membership roles for a composite application. When you create or edit application membership roles, specify levels of access that members in the role have to work with the application, its pages, its membership, and its components:

  • composite application and its pages
  • application components

 

Access to applications and pages

All members of a composite application can view application pages, regardless of their assigned roles. For each role that you define for an application, we can choose one or both of the following additional permissions for Application and Page Access Settings :

  • Also allow members of this role to edit the application and all pages in the application.

  • Also allow members of this role to manage the membership of the application.

Therefore, all application membership roles are derived from one of three application role types used by portal access control:

Application manager

Membership role permits editing the application and all pages in the application as well as managing the membership of the application.

Application membership manager

Membership role permits managing the membership of the application. The role does not permit editing the application and its pages.

Application user

Membership role permits using the application. The role does not permit any level of manager access.

The name of an application membership role does not always imply the permission provided by the underlying application role type. To verify the precise level of access that an application membership role provides, open the Roles portlet in the application: From the application page menu, click Manage Application Roles.

The following table describes the access levels that are available for an application and its pages based on the default membership roles, Administrators and Users. Create new membership roles for an application by customizing these predefined roles.

Object Default Membership Role Access Provided
Application Administrators Administrators own the application (Application Owner).

By default, this role grants the additional permission Also allow members of this role to edit the application and all pages in the application ; this option provides Application Manager access to the application and to every page of the application.

By default, this role also grants the permission Also allow members of this role to manage the membership of the application ; this option provides Membership Manager access.

Users Users can view all pages of the application and use the application components according to the specified component access levels.

If Users have permission to use application templates, they can also create applications from templates.

By default, Users do not have the additional access to edit the application and its pages and to manage application membership. We can specify these additional access levels when we customize this membership role.

Page Users All members of an application can view the pages of an application, regardless of their assigned roles.

Users can edit application pages if they are assigned a role that grants the additional permission Also allow members of this role to edit the application and all pages in the application.

Users assigned a role that does not allow this additional permission cannot edit the pages of the application.

 

Access to application components

Application users will be able to work with the components that are deployed on the pages of an application according to the level of access that you select in the Component Access Settings table of the Roles portlet. Each application component provides its own roles and the access levels for us to select; each access level provides a simple text description. For example, a Team Tasks component might provide the following access levels and descriptions:

  • Reader

    Can read tasks

  • User

    Can read, create, and own tasks

  • Administrator

    Can read, create, and own tasks. Can edit and delete all tasks.

 

Parent Topic

Work with composite applications