Sun Java System Portal Server 7.1 Update 1 Community Guide

Part I Community Features

This part contains the following:

Chapter 1 Overview of Community Features

This chapter contains the following:

Overview of Communities

The portal collaboration feature allows end users to create and join communities, and interact with other community members through a set of collaborative portlet applications (community services). Communities are, therefore, an association of members and services. These services are: file share, shared tasks & events, polls & surveys, wiki, discussions, and blog. For more information on these services, see Part II, Community Services.

Communities are created and managed by end-users. The user can be in one or more roles (visitor, owner, member, invited, pending, rejected). The community owner can set the access control on the community content, membership, and visibility of the community. The owner of the community can also remove the community or transfer ownership of the community. For more information, see Chapter 3, Managing a Community.

The portal administrator can define community templates that defines the layout mechanism and the available services, and end-users can create communities within categories using the available templates. See Chapter 4, Understanding Community Templates for more information. Users must join to take part in community collaboration.

Each portal will have its own set of communities. Communities within a portal will only be visible to users in that portal. The community users are stored in a relational database, one database instance per portal (see Chapter 2, Configuring the Database for more information).

This release includes community management functionality through the Portal Server management console and through the command line. See Technical Note on Technical Note: Managing Sun Java System Portal Server 7.1 Update 1 Communities for more information on managing the communities from the command line.

Community URLs

Community URL refers to the URL of a community page. Typically, the community URL is http://server/portal/dt?dt.community=CommunityName. The community home URL http://server/portal/dt?dt.community will take the user to the community system home page (if visible to the user).

Community URLs can be:

Bookmarked in a browser.
Emailed to another user who can click on the link from their mail reader to access the community.
Entered directly into a browser, by hand.

Community URLs are cross-organization. The same URL will work in any community enabled organization. This allows a user in one organization to send a community URL to a user in another organization. If a community URL is accessed by an unauthenticated user, the user is redirected to a login page and then taken to the community after successfully logging in. The community system home page does not require login. If a user is a member of a community, the community URL will take the user to the community member page. Otherwise, the user will be taken to the community visitor page.

Overview of Community Portlets

The community portlets bundled with the Portal Server implement the community infrastructure.

Community Info Portlet

This application lists all registered members of the community and allows the community owner to add and delete users from the community. As an owner of a community, this application allows the user to manage community membership, change access settings, and delete the community. Community owners can also transfer ownership of the community to a registered member through this portlet.

Registered users can join any community and leave a community at any time. This application allows users to join or leave a community, accept or decline an invitation to join a community, and request for membership to a community.

To allow visitors to search and join communities, the Community Info portlet must be in the visitor's display profile.

Community Portlet

This application allows users to create communities, browse community taxonomy, and perform searches on existing communities and the content posted on the communities.

Community Membership Portlet

This application allows a user to see a list of communities that the user is a member of, communities that the user has been invited to, communities to which the user has a pending membership.

Role Management Portlet

This portlet is deprecated and the equivalent functionality is available through the Community Info Portlet.

Chapter 2 Configuring the Database

This chapter contains the following:

Introduction to Java DB

By default, the Sun Java System Portal Server software uses the Java^TM DB to store configuration and membership for the collaboration feature. The Portal Server software installs and configures the database.

Tip –

For information on switching to enterprise-scale databases, see this article.

The Portal Server software does not manage the Java DB process; it must be manually started and stopped using the Java DB NetworkServerControl class (see Starting, Stopping, and Disabling the Java DB in Sun Java System Portal Server 7.1 Configuration Guide for more information). The default database user name is portal and the password is a random string generated during installation. On a production system, change the credentials to secure the system. See Security for Community Membership and Configuration Database for more information on changing the password for the database after installation.

Database Configuration

The Portal Server software components use Java DB through Java EE JDBC resources. When a new portal instance is created, the Portal Server software creates one JDBC resource for each component that accesses the database. In other words, there is one resource per component, per Portal Server instance.

The resource configuration can be modified using the web container console or command line interface. The database URL for the Java DB community database is of the form jdbc:derby://host[:port]/component_portal-ID. When connecting to Java DB using third-party tools, use the driver org.apache.derby.jdbc.ClientDriver. This driver is in the JAR file /opt/SUNWjavadb/lib/derbyclient.jar.

On a production system, change the credentials to secure the system. Please see the following section to find out how to change the credentials for the database.

Security for Community Membership and Configuration Database

The default database user name is portal and the password is a random string generated during installation. After the installation, change the password and the access permissions of the properties files containing them. Repeat the instructions to change the password for the database for each portal in your environment. Replace portal-ID with the actual portal ID (like portal1, portal2) when changing the password.

To Change the Password for the Database

Restart Java DB.

See Starting, Stopping, and Disabling the Java DB in Sun Java System Portal Server 7.1 Configuration Guide for more information.

Change the password for the default user, portal, by connecting to the communitymc_portal-ID database.

For example, if you are using a GUI like SQuirrel-j, use the SQL editor to execute the following command after connecting to the database.
CALL SYSCS_UTIL.SYSCS_SET_DATABASE_PROPERTY('derby.user.portal', 'your-new-password');

Restart Java DB.

See Starting, Stopping, and Disabling the Java DB in Sun Java System Portal Server 7.1 Configuration Guide for more information.

Verify that the password was set correctly by connecting to the communitymc_portal-ID database with the new password.

For each portal instance:
1. Refer to the web container's documentation and change the password for the jdbc/communitymc datasource to the new password that was set in step 2.
2. Open the PortalServer-DataDir/portals/portal-ID/config/portal.dbadmin file and change the password value for the property community.db.password to the new password that you set in step 2.
3. Change the permission for the PortalServer-DataDir/portals/portal-ID/config/portal.dbadmin file so that it is readable and writable only by the owner.
  
  For example, type chmod 600 portal.dbadmin.
4. Restart the web container.

Chapter 3 Managing a Community

This chapter describes the management of a community and its users. This functionality is made available to a community owner through the Community Info portlet. Similar functionality is made available to system administrator through the Portal Server management console and psadmin command line interface. Please refer to the Technical Note: Managing Sun Java System Portal Server 7.1 Update 1 Communities Technical Note for information on the command line utilities for managing 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. See Appendix A, Migrating Community Templates for more information.

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. It restricts membership by requiring one to request for and be granted a membership - alternatively, 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 Chapter 4, Understanding Community Templates to 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.

Use deleted.xml template to show how a deleted community would be presented to users. See Chapter 4, 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 in Sun Java System Portal Server 7.1 Administration Guide.

Chapter 4 Understanding Community Templates

This chapter contains the following:

Overview of the Community Template

This section contains the following:

What Is A Community Template?

A community template is comprised of a set of services (channels) and the visual layout. However, the layout is not always dictated by the community template as in the case with wiki community template where the layout is dictated by the wiki itself. Community templates define (in the role display profile document) the type of services available for the community, the default settings for each service, and the containers that bind the services.

Physically, a community template is a properties file, and image, plus one or more display profile documents. There are display profile documents, one per community role (such as OWNER, VISITOR, MEMBER). Each role template defines services and the layout associated with the particular role (see Managing Membership for more information on these roles). The content of the role template is represented in a display profile document. In essence, a community template contains the logic for handling different roles (one display profile document per role) and depending on the one or more roles, you get a different set of services and a different layout. There are also display profile documents to customize the content when communities are marked for deletion (deleted.xml) or disabled (disable.xml).

Communities are created from a community template. The system may have any number of community templates. In the Community Sample, end users choose a community template when they create a community.

How Are The Templates Stored?

The community templates are stored on filesystem. Community templates are stored in PortalServer-DataDir/portals/portal-ID/communitytemplates directory (referred to as communityTemplateBaseDir). Note that this means that each Portal (in a multi-portal deployment environment) will and must have its own set of community templates. The resource bundle in communityTemplateBaseDir defines the meta data associated with each template. In addition, each template has its own directory where the role templates are stored.

Example 4–1 Sample `communityTemplateBaseDir`

communityTemplateBaseDir   -+-- template1 -+-- deleted.xml
                            |              |
                            |              +-- disabled.xml
                            |              |
                            |              +-- member.xml
                            |              |
                            |              +-- owner.xml
                            |              |
                            |              +-- visitor.xml
                            |
                           -+-- template2 -+-- deleted.xml
                            |              |
                            |              +-- disabled.xml
                            |              |
                            |              +-- member.xml
                            |              |
                            |              +-- owner.xml
                            |              |
                            |              +-- visitor.xml
                            |
                           -+-- template3 -+-- deleted.xml
                            |              |
                            |              +-- disabled.xml
                            |              |
                            |              +-- member.xml
                            |              |
                            |              +-- owner.xml
                            |              |
                            |              +-- visitor.xml
                            |
                            +-- template1.properties
                            |
                            +-- template1_en.properties
                            |
                            +-- template1_fr.properties
                            |
                            +-- template2.properties
                            |
                            +-- template3.properties
                            |
                            +-- template3_en_US.properties
                            |
                            +--       ...

The display profile disabled.xml and deleted.xml files control the content when the community is disabled or marked for deletion. See Managing a community status for more information.

How Are The Templates Managed?

The portal administrator can add a new community template, update an existing community template, archive and restore community templates on the system, and export community templates from one portal instance to others and/or keep them in sync.

Template Syntax and Semantics

Each template is made up of one or more role templates (member.xml, owner.xml, visitor.xml, deleted.xml, disabled.xml) in XML format. The template directory includes the XML files for the roles that it will serve; for example, member.xml for the community member, owner.xml for the community owner, and visitor.xml for the community visitor.

Each role template is a display profile document for community users in that role. The file must be based on the display profile DTD.

<?xml version="1.0" encoding="utf-8" standalone="no"?>
<!DOCTYPE DisplayProfile SYSTEM "jar://resources/psdp.dtd">
<DisplayProfile version="1.0" priority="%COMMUNITY_DP_PRIORITY%">
	<Properties/>
	<Channels>
		<Container name="%COMMUNITY_CONTAINER%" provider="JSPTableContainerProvider">
			<Properties>
				<String name="title" value="%COMMUNITY_NAME%"/>
				<String name="description" value="%COMMUNITY_DESCRIPTION%"/>
				<Boolean name="compileToRealPath" value="true"/>
			</Properties>
			<Available>...</Available>
			<Selected>...</Selected>
			<Channels>...</Channels>
	</channels>
	<Providers/>
</DisplayProfile>

The tokens (surrounded by %), described below, in the display profile are dynamically replaced by actual values by the template engine when a community is created.

%COMMUNITY_NAME%: Specifies the (user-friendly) name given to the community. For example, tourists.
%COMMUNITY_ID%: Specifies the unique string identifying the community. This name is strictly an internal representation and does not get exposed in the user interface. For example, jdo__tourists.
%COMMUNITY_DESCRIPTION%: Includes a description of the community.
%COMMUNITY_CONTAINER%: Specifies the top-level container for the community. For example, jdo__touristsContainer.
%COMMUNITY_DP_PRIORITY%: Specifies the display profile merging priority given to the resulting community display profile. Each role is given a different value. By default, 1000 for the visitor role, 1005 for the member role, and 1010 for the owner role.
%COMMUNITY_SEARCH_URL%: Specifies the Search server URL for the community.
%COMMUNITY_CONTENTS_SEARCH_DB%: Specifies the search database for the community content.
%COMMUNITY_DISCUSSIONS_SEARCH_DB%: Specifies the discussions database.
%PORTAL_ID%: Specifies the ID of the portal. For example, portal1.

Template Descriptor File

Each template includes a resource bundle properties file which defines the meta-data associated with that template. The resource bundle is referred to as the descriptor file that can be localized. Each template descriptor file (must) define the following properties:

id: Specifies an unique ID of the template. The ID must match the template directory name. For example, Baseball for a template directory named Baseball with role templates (or XML files) for all three supported roles.
name: Specifies an user-friendly name used in the user interface (portal desktop) to identify the template. For example, Baseball Template.
description: Contains a verbose description of the template including the services it offers. For example, Baseball-themed template containing the following services: Player Statistics, Game Discussions, TV Schedule, and Online Chat.
tokens: Includes the list of tokens used in the template role files. This merely serves an informative purpose and is not required. For example, %COMUNITY_ID% %COMMUNITY_DESCRIPTION% %COMMUNITY_CONTAINER%.
previewImageURI: Specifies either the absolute or relative URI to the portal context. For example, http://images.domain.com/images/baseball.jpg. The relative URI must be relative to the portal web-app context path.

Example 4–2 Sample Descriptor File

id=Baseball
name=Baseball Template
description=Baseball-themed template containing the following services:
 Player Statistics, Game Discussions, TV Schedule, and Online Chat
tokens=%COMUNITY_ID% %COMMUNITY_DESCRIPTION% %COMMUNITY_CONTAINER%
previewImageURI=http://images.domain.com/images/baseball.jpg

Creating and Modifying a Template

To create a new or modify an existing template, following the instructions in this section. You can create a template in one of the following three ways:

Export the template, add content, and import the content using the psadmin utility.
Create content and import the content to overwrite existing template.
Add new files to existing templates.

To Create a New Template for Single Portal Environment

Go to the communityTemplateBaseDir.

Create a:
- New directory for the new template
- Copy an existing template to the new template directory
For example, type:
cd PortalServer-DataDir/portals/portal-ID/communitytemplates mkdir NewTemplate cp 2column/* NewTemplate/

Modify the role based display profile documents in the new template directory as needed.

For more information on the role based display profile documents, see Template Syntax and Semantics.

Create and edit the properties file to include the properties described in Template Descriptor File and save the file.

For example, to create a new properties files for the new template, type:
cp 2colimn.properties NewTemplate.properties
Or,
touch NewTemplate.properties
Note –
In order to see the newly added template, log out of any current portal session and re-login to see the change.

To Customize or Modify an Existing Template for Single Portal Environment

Go to the communityTemplateBaseDir/template directory and open the file you wish to modify.

Log out of any current portal session and re-login to see the change.

To Create a Template for Multi-Portal Environment

In a muti-portal environment (when there are more than one portal on the system), use PAR mechanism (as opposed to directly editing files in communityTemplateBaseDir) so that the change of community templates can be applied across multiple portals. This will allow all the portals to have the same set of community templates. If you do not wish to have synchronized environment across portals, use the instructions outlined in To Create a New Template for Single Portal Environment.

Either use psadmin export --type desktop to export desktop data (which includes community templates) and then export it so the content can be edited or, create a new PAR structure from scratch with only the community templates and no other desktop data.

Follow instructions in To Create a New Template for Single Portal Environment to edit content.

Create a new PAR file which contains:

   -+-- META-INF -- MANIFEST.MF
    |    
    +-- pbfiles -+-- communityTemplateBaseDir -+-- template1 -+-- deleted.xml
    |                                          |              |
    |                                          |              +-- disabled.xml
    |                                          |              |
    |                                          |              +-- member.xml
    |                                          |              |
    |                                          |              +-- owner.xml
    |                                          |              |
    |                                          |              +-- visitor.xml
    |                                          |
    |                                          +-- template1.properties
    |                                          |
    |                                          +-- template1_en.properties
    |                                          |
    |                                          +-- template1_fr.properties
    |                                          |
    |                                          +-- ...
    |
    +-- static -- community -- images -- template1.gif

Edit or add content as needed.

Create a new PAR file.

Use psadmin import subcommand to import the PAR content across all portals.

If you exported all desktop data, note that psadmin export subcommand will export all desktop data; if you create a new PAR structure from scratch with only the community templates, the command will only export community templates.

Tip –
For more information, see the psadmin export in Sun Java System Portal Server 7.1 Command Line Reference.

Chapter 5 Customizing Sun Java Web User Interface Theme

This chapter contains the following:

Introduction to Sun Java Web User Interface Theme

The defaulttheme.jar file in PortalServer–base/lib directory is an instance of the Sun Java Web User Interface Components theme JAR file and during installation, the configurator appends PortalServer–base/lib/defaulttheme.jar onto the web container's shared server classpath. The defaulttheme.jar file controls many default properties for the Community Sample including fonts and colors.

Customizing the User Interface

This section contains the following:

To Use Sun Java Web User Interface Theme in a Page

In the JSP^TM files that generate the <head> section of the HTML (or the header.jsp file), you can designate a Sun Java Web User Interface Components theme to be used for the entire page. For example:
<pui:setupTheme themeName="defaulttheme" .../>
To use Sun Java Web User Interface Components theme in a page, the porletSetupTags.tld tag library descriptor file must be included; otherwise, the <pui:setupTheme...> will fail. This file must be located where the JSP files can access it. For example, in the community sample, it is located at PortalServer-DataDir/portals/portal-ID/desktop/community_sample/tld directory.

To Modify or Create a New Sun Java Web User Interface Theme

Make a copy of defaulttheme.jar file. For example, copy this file to PortalServer-DataDir/portals/portal-ID/.

Unpack the defaulttheme.jar file and modify the following files (as needed).
- CSS files
- Image Files
- JavaScript^TM
- Properties Files
For more information on these files, see the Theme for Sun Java Web User Interface Components Tech Note. When modifying the defaulttheme.jar file, leave the manifest file intact.

Make a JAR of the files and change the server classpath to point to the new location.

When packaging the theme into a JAR file, specify an existing manifest file. For example, type jar cmf META-INF/MANIFEST.mf com to retain the original manifest file. This command will prevent the jar command from auto-generating a new manifest file.

For example, change classpath from PortalServer-base/lib/defaulttheme.jar to PortalServer-DataDir/portals/portal-ID/defaulttheme.jar.

In a multi-portal environment, you can:
- Have all portals point to a single theme.jar file.
- Or, have each portal associated with its own theme.jar file.
  
  For example:
  - The web container serving portal1 can have its server classpath pointing to PortalServer-DataDir/portals/portal1/theme/portal1theme.jar file.
  - The web container serving portal2 can have its server classpath pointing to PortalServer-DataDir/portals/portal2/theme/portal2theme.jar file.

Restart the web container for the changes to take effect and reload the Community Sample in your browser to see the changes.

Tip –
It is not necessary to have the theme in a JAR file format. Alternatively, you can set up the server classpath to include the directory containing the exploded theme hierarchy. This is especially useful during development cycles since it allows you to edit individual files and see the result instantly reflected.

Changes in properties file require a web container restart; changes to Javascript, images, and CSS files will be reflected without restarting the server.

To Change the `defaulttheme` to Your `customtheme`

The Sun Java Web User Interface Components' defaulttheme can be defined in dynamic and static files. To change the defaulttheme to your customtheme, do the following.

Copy the community sample par source files to your custom directory.

For example, type cp -Rf /opt/SUNWportal/par-src/community_sample /tmp/mypar.

Search for defaulttheme references in your custom directory, and for each file, replace defaulttheme with your customtheme.

For the Community Sample, defaulttheme is referenced in dynamic and static files.

Create the PAR file.

For example, type /opt/SUNWportal/bin/psadmin create-par --dir /tmp/mypar /tmp/mypar.par.

Import the PAR file.

Note –
Use the --skip-node-validation option if you are importing display profile documents to a user distinguished node. Use the --overwrite option to overwrite the exiting display profile documents and files.

For example, type /opt/SUNWportal/bin/psadmin import --adminuser amadmin --passwordfile passwordfile --overwrite --skip-node-validation --portal portal1 /tmp/mypar.par.

Redeploy the portal.

For example, type /opt/SUNWportal/bin/psadmin redeploy --adminuser amadmin --passwordfile passwordfile.

Chapter 6 Modifying the Properties and Attributes

This chapter contains the following:

`communitymc.properties` File

This file configures the community membership and configuration component of the Portal Server software. For the most part, this file contains low level configuration that need not be modified. For performance reasons, if the community feature is not used, this file must be changed to avoid calls to Java DB on each portal request.

To modify the file, log into any system that has portal server installed as superuser and access the file in the PortalServer-DataDir/portals/portal-ID/config/ directory.

The file contains the following variables:

manager.contributors

Specifies the active membership and configuration contributor types in the system. By default, this list includes:

am-global: Access Manager service schema
am-org: Access Manager organizations
am-role: Access Manager roles
am-frole: Access Manager filtered roles
jdo: Java DB, through Java Data Objects (JDO) layer

Each of these contributor types provides membership and configuration data from a different source.

`communitymgmnt.properties` File

This file contains configuration for the community management SDK component. The configuration variables defined in the communitymc.properties file, in most cases, need not be modified. To modify the file, log into any system that has portal server installed as superuser and access the file in the PortalServer-DataDir/portals/portal-ID/config/ directory.

The file contains the following (modifiable) variables:

ps-search-url: Specifies the URL of the search server to use when creating communities.
ps-dp-priority-base: Specifies the base value used to set display profile priorities for created communities.
ps-community-notification-notifier-classes: Specifies the implementation classes to use to send notification. The following implementation is available: com.sun.portal.community.notification.impl.JavaMailNotifierImpl.
ps-community-notification-types: Specifies types of events for which notification is to be triggered. The following event is available: user_invited. Leave the value empty if you do not wish to use the notification feature.
mail.transport.protocol: Specifies the mail protocol (smtp) to use. See JavaMail^TM specification for more information.
mail.imap.host: Specifies the hostname of the mail server. See JavaMail specification for more information.
mail.debug: Specifies the debug mode for JavaMail. See JavaMail specification for more information.
ps-community-notification-javamail-default-sender-addr: Specifies the default sender address if there is none available for the user sending the notification.
ps-community-notification-javamail-authenticator-class: Provides simple authentication implementation to be used with JavaMail. The following implementation is available: com.sun.portal.community.notification.impl.SimpleAuthenticator. See JavaMail specification for more information.
ps-community-notification-javamail-simpleauthenticator-user: Specifies the user name to be used with the SimpleAuthenticator implementation.
ps-community-notification-javamail-simpleauthenticator-password: Specifies the password to be used with the SimpleAuthenticator implementation.

Community Webservice URL

Community search and administration functionality involves a community webservice. By default, the community webservice URL contains the same host as the first Portal instance. In a multi-node installation that uses a load balancer, you can change the community webservice URL to use the load balancer host.

To get and set the community webservice URL, type:

./psadmin get-attribute -u amadmin -p portal-ID -m communities -a WebServicesURL

./psadmin set-attribute -u amadmin -p portal-ID -m communities -a WebServicesURL URL

Here:

amadmin: Specifies the administrator's distinguished name.
portal-ID: Specifies the portal ID.
WebServicesURL: Specifies the value for the WebServicesURL attribute. For example, the URL can be of the format http://foo.com:8080/communitymanagerwebservices/communitymanagerwebservices. Please note that the communitymanagerwebservices/communitymanagerwebservices part of the URL must not be changed.

Note –

There is no default value for the WebServicesURL attribute. By default, an empty value indicates that the host of the first Portal instance will be used.

Part I Community Features

Chapter 1 Overview of Community Features

Overview of Communities

Community URLs

Overview of Community Portlets

Chapter 2 Configuring the Database

Introduction to Java DB

Database Configuration

Security for Community Membership and Configuration Database

To Change the Password for the Database

Chapter 3 Managing a Community

Managing Access Control

Available Settings

Common Configurations

Public Community

Private Community

Managing Membership

Restricted Membership Workflow

Inviting Users

Banning Users

Managing a community status

Enabling and Disabling a Community

Deleting and Restoring a community

Managing Categories

Chapter 4 Understanding Community Templates

Overview of the Community Template

What Is A Community Template?

How Are The Templates Stored?

Example 4–1 Sample communityTemplateBaseDir

How Are The Templates Managed?

Template Syntax and Semantics

Template Descriptor File

Example 4–2 Sample Descriptor File

Creating and Modifying a Template

To Create a New Template for Single Portal Environment

To Customize or Modify an Existing Template for Single Portal Environment

To Create a Template for Multi-Portal Environment

Chapter 5 Customizing Sun Java Web User Interface Theme

Introduction to Sun Java Web User Interface Theme

Customizing the User Interface

To Use Sun Java Web User Interface Theme in a Page

To Modify or Create a New Sun Java Web User Interface Theme

To Change the defaulttheme to Your customtheme

Chapter 6 Modifying the Properties and Attributes

communitymc.properties File

communitymgmnt.properties File

Community Webservice URL

Example 4–1 Sample `communityTemplateBaseDir`

To Change the `defaulttheme` to Your `customtheme`

`communitymc.properties` File

`communitymgmnt.properties` File