Understanding Portal Server Communities
This chapter contains the following:
Managing Access Control
While the concept of “community” has a general notion of being publicly open and making information accessible to everyone, there is a great need for establishing access control around the communities. As in the case of enterprise-based communities, the audience of certain communities might need to be restricted and the data posted to these communities be kept private and secure. This section describes the available access control settings and the common configurations for them.
Available Settings
Following are the three community aspects on which access controls can be set based on requirement of a community.
- Membership Access
-
-
Unrestricted Membership (Public): A community with an unrestricted membership is open for anyone to join.
-
Restricted Membership (Private): A community with a restricted membership requires a user to make a request (to the owner of the community) and be granted or denied of the membership. Alternatively, the owner can invite or explicitly add one or more users to the community.
-
- Community Listing
-
-
Listed (Public): A community is registered in the community categories and can be browsed and searched by anyone.
-
Unlisted (Private): A community cannot be searched and is not browsed in the community categories.
-
- Secured Content
-
-
Unsecured (Public): The data posted on the community has the potential of being searched and accessed by non-members.
-
Secured (Private): All data posted on the community will be strictly protected and can only be searched and accessed by the members.
-
Common Configurations
A community owner or a system administrator can control the various aspects of the access control during or after creation of the community. Note that each setting described in the Available Settings section is independent of each other. In other words, selecting one option for a setting will not influence the behavior or selection of the other settings. For instance, a community with (unrestricted) membership can be unlisted or its content can be made secured. Owner of a community can customize the access control based on the nature of the community. The two most common configurations are explained here.
Public Community
A public community is open for anyone to join and gain membership. The community is listed in the community categories and can be browsed and searched by anyone. The content posted on community is also searchable and accessible to anyone.
Communities created on previous release of Portal Server software are considered public communities and will operate like a public community when the system is upgraded to this release of the Portal Server software.
Private Community
A private community is the most secure form of a community. It is hidden from the community categories thus cannot be browsed nor searched. Private community is a community that is unlisted, secure, and having restricted membership. The community owner can invite or manually add users to the community. The content of the community is protected from non-members such that they will not be able to view or search any posted content.
Managing Membership
A user can be assigned different roles in a community. The two primary roles are OWNER and MEMBER. A user in MEMBER role has all the regular member privileges. If it is assigned the OWNER role too, it will assume additional privileges to manage the community. The privileges and the content presented to the user are controlled by the merge of the corresponding display profiles for each of the role assigned to a user. System administrator must be careful when designing the display profiles templates for each community role. Please see the community template chapter for more details.
A non-member user implicitly assumes the VISITOR role and as a result, the visitor.xml is always merged when a non-member user visits a particular community page. A user is referred as a non-member when it either has no explicit role or has transient roles like BANNED, INVITED, PENDING and REJECTED.
Restricted Membership Workflow
In order for a user to join a community which is either private or has a restricted membership, a membership request should be made by the interested user. The owner of the community then either approves or denies the request. When approved, the user immediately becomes a member of the community. On the other hand, a denied user receives notice of rejection when the user logs into the portal and upon acknowledging the rejection, the user returns to the visitor status. A denied user can then submit request again at a later time. Owners can ban certain users if the owner does not even want the users to submit a request for membership.
VISITOR --request membership--> PENDING/VISITOR--> approved--> MEMBER VISITOR --request membership--> PENDING/VISITOR--> denied | -->REJECTED/VISITOR --acknowledges--> VISITOR
Inviting Users
As an owner of a community, one can send invitation to users to join the community. An invited user can see the invitation when the user logs into portal. The user then has an option to either accept or decline the invitation.
VISITOR--> invited--> INVITED/VISITOR--> accepts--> MEMBER VISITOR--> invited--> INVITED/VISITOR--> declines--> VISITOR
When the system is set up properly, an invitation message is sent to the invited users through email. In order to receive an invitation through email, the user must have email address properly configured in their portal.
Banning Users
Banning is a process by which the owner can prohibit certain users from accessing the community. Both members and non-members, as well as owners, can be banned from the community and in the case of a restricted membership community, a banned user cannot even submit a request to join the community.
A banned user can be unbanned by the owner and the user's prior privileges are reinstated. If the user was a member before getting banned, the user becomes a member after getting unbanned. Likewise, when an owner gets banned from a community and is then unbanned, the owner becomes the owner of the community again.
MEMBER--> banned--> BANNED/VISITOR--> unbanned--> MEMBER OWNER/MEMBER--> banned--> BANNED/VISITOR--> unbanned--> OWNER/MEMBER
Managing a community status
This section contains the following:
Enabling and Disabling a Community
A portal administrator, using either Portal Server management console or psadmin CLI, can disable a community. Likewise, only the portal administrator can enable a disabled community. Access to a disabled community is blocked to everyone including members and owners. An attempt to search for any content posted on a disabled community would yield no result. By default, a newly created community is enabled.
Use disabled.xml template to show how a disabled community would be presented to users. See Understanding Community Templatesto understand the display profiles for a community template.
Deleting and Restoring a community
A community owner or a system administrator can delete a community. When a community is deleted, the community itself and the data pertaining to the community are not accessible. However, in the back-end storage, the data still remains and thus the community can be restored on demand. The task of restoring a deleted community is done by the portal administrator. This undo functionality is made available to reverse a malicious or accidental deletion of a community. Since the deletion is not permanent, a new community by the same name can not be created. A permanent and persistent removal of a community is currently not supported. But we can use psadmin subcommand destroy-community to remove the community permanently.
Use deleted.xml template to show how a deleted community would be presented to users. See Understanding Community Templates to understand the display profiles for a community template.
Managing Categories
The category tree used in creating communities as well as browsing communities is provided by the taxonomy of the search server. To manage them, please see Managing Categories.
- © 2010, Oracle Corporation and/or its affiliates