Sun Java System Portal Server 7.2 Technical Reference

Previous: Part X File Formats

Part XI Service Providers and Portlets

This part includes an overview of the service providers and portlets available out-of-the-box with the Portal Server software. It also includes information on the portlet application framework and provides detailed instruction on how to deploy and configure the portlets.

Chapter 77 Service Providers

This chapter provides common customization tasks for modifying the Search provider and Discussion provider.

Overview of the Service Providers

This section describes about service providers such as Search Provider and Discussion Provider.

Search Provider

The Search provider uses JSPProvider to access the Portal Server back end services. The Search provider users JavaServer Pages^TM (JSP^TM) helper tag libraries to avoid using Java^TM scriptlets. The searchServer is a global service list type attribute that is configured and updated at installation time. The Search provider is responsible for directing the search request to the appropriate back end Search Engine server.

See the Sun Java System Portal Server 7.2 Technical Reference for the display profile properties you can set for the provider.

Discussion Provider

This section describes about the Discussion Provider.

Chapter 78 Portlet Application Framework

This chapter contains the following sections:

Overview of the Framework

The Portal Server portlet applications framework provides a convenient method for customizing, configuring, and deploying portlet applications. This can be done by editing a single properties file and executing several well-defined ant targets.

Portlet application source files are located in the PortalServer-DataDir/portals/portal-ID/portletapps directory. Each subdirectory here contains an ant build.xml file, a Java properties file named tokens.properties, and the source files for the portlet web application.

Ant Targets

Perform actions on the portlet applications by executing ant targets. The following targets are supported:

customize: Builds the deployable portlet web application (WAR) by performing token substitution on the WAR source files. The tokens and values are read from the tokens.properties file.
config_backend and unconfig_backend: Configures any data sources that the portlet requires. For example, it might create a user and tables in a database. The unconfig_backend target undoes the actions performed by the config_backend target.
config_resource: Creates any Java^TM EE resources required by the portlet. For example, it might create a JDBC^TM resource. As there is no unconfig_resource, resource removal must be performed manually by using the web container administration console or command line.
deploy and undeploy: Deploys the portlet web application that was built using the customize target. The undeploy target removes the portlet web application.

Installing the Portlet Application

The Portal Server software sets up a default portal under the portal1 ID. It customizes, configures, and deploys all portlet applications for this portal using default values and values provided at install time. The default portal is a special case. Thereafter, when a new portal is created, the PortalServer-DataDir/portals/portal-ID/portletapps directory is populated, the tokens.properties files are filled with default values, but the portlet applications are not deployed.

Example 78–1 Reconfiguring the File Sharing Portlet Application

By default, the file sharing portlet application is configured to store files in a database, but it can also be configured to use the file system. In this example, the file sharing portlet in the default portal is re-configured to use the file system.

Undeploy and unconfigure the file sharing portlet application in the default portal located at /var/opt/SUNWportal/portals/portal1/portletapps/filesharing directory.

To undeploy, run ant undeploy and to unconfigure, run ant unconfig_backend.
Edit the File Sharing portlet's tokens.properties file and modify the following tokens:

REPOSITORY_TYPE

Change the value of this token from Database to FileSystem.

FILE_SYSTEM_REPOSITORY_ROOT_DIR

Change the value of this token to /export/filesharing/portal1 to change the location where the files are stored on the file system.
Save the file.
Build the deployable portlet web application using the customize target ant customize.
Configure the portlet application's data sources by running ant config_backend. Here, this command will simply create the file system directories used by the portlet application.
Deploy the portlet application by running the command ant deploy.

Chapter 79 Overview of the Community Services

A community service is an application that runs in a community context to provide per-community collaborative functions to end-users. Community services are portlets or providers. This chapter contains a description of the community services available with the Portal Server software.

Community Services

The Portal Server includes the following community services:

File Sharing

The file sharing (JSF-based) application offer a hierarchical view of a file repository similar to File System browsing applications provided by the OS. Through this hierarchical view, the user can browse the repository, download files, upload files, create folders, delete and rename files and folders, copy and move files and folders. All these user interactions are done through a portlet.

This service can be customized by modifying the defaulttheme.jar file (see Customizing Sun Java Web User Interface Theme) and default deployment values can be modified in the tokens.properties file (see Configuring File Sharing Portlet).

Survey

The Survey (JSF-based) application allows users to create surveys for the community, answer the surveys , then review and search survey results in the portlet. There are two types of users for the Survey portlet application: end user and community administrator. All members of a community can create a survey.

Polls

The Poll (JSF-based) application allows users to create polls for the community, answer the polls, then review and search poll results in the portlet. There are two types of users for the Poll portlet application: end user and community administrator. All members of a community can create a poll.

Shared Events

Shared Tasks

Search

The Search service allows community users to search for content within a community. This channel is provider-based.

Discussions

This application allows discussions in the context of the community. It also supports HTML discussions with links. This channel is provider-based.

Subscriptions

This application allows community user's to subscribe to discussions out of the community discussion channel, and to save searches from the community search channel. It differs from the developer sample, in that it does not allow category subscriptions. This channel is provider-based.

Blog

This application allows users to manage weblog posts from a portal page. Users can post, edit, and delete weblog entries. This portlet includes a simplified user interface to create weblogs and weblog user accounts. For more information, see Managing the Blog Portlet.

Wiki

This application supports wiki-based communities and portlets. An entire community can be set up as a wiki (with portlets within it) and single portlets within a community can also be wikis. The wiki portlet supports both text and HTML modes. An HTML wiki uses the Xinha HTML editor and includes a portlet picker for easy selection of portlets to include within a wiki page. The Wiki can be configured to use either files or database at the back-end. The Developer Sample desktop also uses a wiki portlet in its wiki tab.

The Wiki portlet uses JSPWiki (http://jspwiki.org JSPWiki home page) and the HTML editor uses Xinha (http://xinha.python-hosting.com Xinha home page).

For more information on:

Deploying this portlet, see Deploying the Wiki Portlet.
Modifying this portlet tokens, see Configuring the Wiki Portlet.

Most of these services use Sun Java Web User Interface Components. These services allow for customizations through modifications to stylesheet. See Customizing Sun Java Web User Interface Theme for more information.

Chapter 80 Search Provider

This chapter provides common customization tasks for modifying the Search provider and Discussion provider.

Overview of Customizing the Search Provider

The Search provider (SearchProvider) furnishes a basic reference user interface that contains both search and browse functionality. Search functionality includes basic search mode, and advanced search for more complex searches. You can perform specific field searches in advanced search mode. For example, while in advanced mode, you can search within the title, URL, last modified date, author, and so on.

SearchProvider provides a link for category browsing. In addition, you can create a taxonomy for the Search Engine along with category filter rules. You can browse through the taxonomy tree and view documents within a category through the Search provider interface.

Search Provider Design

See the Sun Java System Portal Server 7.2 Technical Reference for the display profile properties you can set for the provider.

Search JavaServer Pages and Tag Libraries

The Search provider consists of two stages (input form and results) and the JSPs used by the Search provider fall into one of those two stages.

The following Example 80–1explains the JSP layout for searchContent.jsp. In the input stage (Stage 1), searchContent.jsp makes use of searchMenu.jsp and psSearch.jsp to set up the initial interface. The basicSearch.jsp file is used for a basic search and advancedSearch.jsp file for an advanced search. The description menu (that is, the Full, Brief, and Title menus) is displayed for both basic and advanced searches by descMenu.jsp file. The browseHeader.jsp file defines the browse interface.

In the results stage (Stage 2), one of three JSPs is used: browseOnly.jsp file sets and executes the parameters for category browsing using the Search tag library, and includes the browseResults.jsp page; browseSearch.jsp file sets and executes the parameters for searching and browsing within categories using the Search tag library and includes browseSearchResults.jsp; and searchOnly.jsp file sets and executes the parameters for search using search the Search tag library and includes results.jsp and score.jsp for the match relevance. The pageFooter.jsp file displays the list of pages, Next, and Previous links.

Example 80–1 JSP Layout for `searchContent.jsp`

searchContent.jsp
	|
	|------>searchMenu.jsp
	|
	|------>psSearch.jsp
	|
	|------>basicSearch.jsp----->descMenu.jsp (if search mode is basic)
	|
	|------>advancedSearch.jsp-->descMenu.jsp (if search mode is advanced)
	|
	|------>browseHeader.jsp (if browse mode is selected)
	|
	|					STAGE 1 INPUT
	_______________________________________________________________________________
	|	|
	|	|				STAGE 2 INPUT
	|	|
	|	|--->browseOnly.jsp----->browseResults.jsp (category browsing in browse mode)
	|
	|------>browseSearch.jsp--->browseSearchResults.jsp (only for category search)
	|
	|------>searchOnly.jsp----->results.jsp--->score.jsp(displays the match relevance)
	|
	|------>pageFooter.jsp

See the Sun Java System Portal Server 7.2 Technical Reference for more information on the Search JSP files.

The Search JSPs use the following tag libraries, which ship with the Portal Server software:

Jakarta tag library, for any generic tags
Desktop tag library, for the Portal Server software related information
Search tag library to cover all Search Engine server access functionality and to provide a tag-based wrapper for the existing public search and SOIF API

See the Sun Java System Portal Server 7.2 Technical Reference for more information.

Debugging the Search Providers

The Portal Server software provides files to help debug the Search Providers.

The following directory contains various search log files:

PortalServer-DataDir/searchservers/search1/logs

The following search log file records the search query sent to the Search Engine by the Search server:

PortalServer-DataDir/searchservers/search1/logs/rdm.0.0.log

Customizing the Search Provider

This section describes how to perform some common customizations on the Search provider.

To Add last-modified to the Search Result Display

Modify searchOnly.jsp file by adding last-modified to the list of viewAttributes.

For example:

<search:setViewAttributes viewAttributes="hl-url,hl-title,hl-description,score,content-length,hl-classification,last-modified"/>

Modify results.jsp file to display the last-modified date for document results using the SOIF getValue tag.

For example:

<% if (formbean.getDescription().equals("full")) { %>
    <FONT color=<%=tFontColor%> face=<%=tFontFace%>><search:getValue soifAttribute="description" escape="false"/></FONT><BR>
    <FONT color=#707070 face=<%=tFontFace%>><search:getURL escape="true"/><BR>
    <search:getValue soifAttribute="content-length" id="sz"/>
    <search:getValue soifAttribute="last-modified"/><BR>
<% } %>

Run the touch command.

For example, type touch *.jsp.

Reload the Desktop to verify the change.

To Remove content-length from Search Results

(Optional) Modify searchOnly.jsp file by removing content-length from the list of viewAttributes.

The line to modify is the following:
<search:setViewAttributes viewAttributes="hl-url,hl-title,hl-description,score,content-length,classification hl-classification"/>
Remove content-length from this line.

Modify results.jsp file by removing the line that displays the content-length.

Comment the lines as shown here:

<%--
	<search:getValue attribute="content-length" id="sz"/>
	<jx:declare id="sz" type="java.lang.String"/>
	<%
		int sizek = 1;
		try {
			sizek = Math.max(1, (Integer.parseInt(sz) + 512)/1024 );
		} catch (Exception e) {
		}
	%>
	<i18n:message key="size" bundle="searchjsp"/>
	<%= sizek %>k&nbsp;
--%>"

Run the touch command.

For example, type touch *.jsp.

Reload the Desktop to verify the change.

To Remove Author From the Advanced Search Interface

Comment out or remove the author related HTML from the advancedSearch.jsp file.

For example:

<!--     -->
<!-- To disclude the "author" row, remark out the following section -->
<!--     -->
<TR>
    <td valign=middle align=right height=40><FONT color=<%=tFontColor%> face=<%=tFontFace%>><nobr> <LABEL FOR="advAuthor">Author</LABEL>
    <SELECT NAME="authorOp">
    <OPTION VALUE=<%=SearchContext.CONTAIN%> <%=formbean.authorOpSelection(SearchContext.CONTAIN)%>>does</OPTION>
    <OPTION VALUE=<%=SearchContext.NOTCONTAIN%> <%=formbean.authorOpSelection(SearchContext.NOTCONTAIN)%>>does not</OPTION>
    </SELECT>contain&nbsp;</FONT></nobr></TD>
    <td valign=middle align=left height=40><INPUT TYPE="text" NAME="authorVal" id="advAuthor" VALUE= "<%=SearchContext.htmlEncode(formbean.getAuthorVal())%>"></TD>
</TR>

Comment out author- related lines in advQuery.jsp file.

if (!formbean.getAuthorVal().equals("")) {
    h = new HashMap();
    h.put(SearchContext.OPERAND, "author");
    h.put(SearchContext.OPERATION, formbean.getAuthorOp());
    h.put(SearchContext.VALUE, formbean.getAuthorVal());
    l.add(h);
}

Run the touch command.

For example, type touch *.jsp.

Reload the Desktop to verify the change.

To Add a New Field to Advanced Search

Uncomment the keywords section in advancedSearch.jsp file.

<!--     -->
<!-- To Include the "Keywords" row, unremark the following section -->
<!--
<TR>
<td valign=middle align=right height=40><FONT color=<%=tFontColor%> face=<%=tFontFace%>><nobr> <LABEL FOR="advKeywords">Keywords</LABEL>
<SELECT NAME="keywordsOp">
<OPTION VALUE=<%=SearchContext.CONTAIN%> <%=formbean.keywordsOpSelection(SearchContext.CONTAIN)%>>does</OPTION>
<OPTION VALUE=<%=SearchContext.NOTCONTAIN%> <%=formbean.keywordsOpSelection(SearchContext.NOTCONTAIN)%>>does not</OPTION>
</SELECT>contain&nbsp;</FONT></nobr></TD>
<td valign=middle align=left height=40><INPUT TYPE="text" NAME="keywordsVal" id="advKeywords" VALUE= "<%=SearchContext.htmlEncode(formbean.getKeywordsVal())%>"></TD>
</TR>
-->

Remove the  comment marks from this section.

Add the keywords to advQuery.jsp file.

if (!formbean.getKeywordsVal().equals("")) {
  h = new HashMap();
  h.put(SearchContext.OPERAND, "Keywords");
  h.put(SearchContext.OPERATION,formbean.getKeywordsOp());
  h.put(SearchContext.VALUE, formbean.getKeywordsVal());
  l.add(h);
}

Run the touch command.

For example, type touch *.jsp.

Reload the Desktop to verify the change.

To Access Search Channel Directly

Type the following URL in your browser:

http://server:port/portal/dt?provider=JSPDynamicSingleContainer&JSPDynamicSingleContainer.selectedChannel=Search&last=false&action=content

Modify all the links to use these extra parameters in the URL. For example, edit searchMenu.jsp file as follows:
<nobr>  <a class=noUnderline href="<%=dpurl%>?mode=basic">Basic Search</a>  </nobr>

Replace the bold portion with:

http://server:port/portal/dt?provider=JSPDynamicSingleContainer&JSPDynamicSingleContainer.selectedChannel=Search&last=false&action=content

Chapter 81 Discussion Provider

This chapter describes about the Discussion Provider. The sections available in this chapter are:

Overview of Customizing the Discussion Provider

The DiscussionProvider is JSPProvider based and hence customizable. It uses the Desktop themes. It retrieves data from the back end Search service using search taglibs and API. The discussions and comments are stored as separate Resource Descriptors (RDs) in the discussion database.

The DiscussionProvider includes features such as discussion threads, starting discussions based on documents or new topics, searching discussions, and rating discussions. By default, the Discussions channel is available on the sample portal for anonymous users. However, an anonymous user cannot subscribe to a discussion or edit the Discussion channel.

The DiscussionProvider supports a full view (through the Discussions channel) and a lite view (through the DiscussionLite channel.) It has the following main functions:

Start a new discussion from the discussion channel.
Start a new discussion based on web documents from the search channel.
Add a comment to an existing discussion or post a reply to an existing discussion.
Rate all discussions and comments. Note that the displayed ratings are based on an algorithm such that the rating for any comment goes up gradually. For example, a comment has to be rated important three times before it is marked as important.
Search all discussions and search within a discussion. These functions are routed to the search provider. The displaySearch property can be disabled if the search feature is not required in the discussion channel. Users can also search by rating in Advance Search.
Authenticated users can choose to subscribe to a particular discussion by selecting the subscribe link. The request is handled by the SubscriptionProvider. The displaySubscription property can be disabled if the feature is not required. By default, the value is true.

A Discussion Lite view retrieves main posts sorted by last-modified date and has pagination so users can access older discussions. View discussion displays each discussion subtree. The main item is displayed in detail and the subtree is displayed below the main item.

View discussion includes:

Several filters on the page. A document display can be based on filters such as document rating (irrelevant, routine, interesting, important, and must read).
Display preference can be set to threaded or flat display.

Expansion threshold helps to control displayed items in the subtree. The users can choose to expand only highly rated documents, or expand all or collapse all. Default value is collapse all. Expand all will expand all the filtered comments. It will also show a description of the discussion, provide a menu for rating the discussion, and allow the user to post a reply.

Discussion Service Channels

The DiscussionLite channel and the Discussions channel are based on the DiscussionProvider.

DiscussionLite Channel

The DiscussionLite channel displays the top twenty discussion titles (which can be reconfigured) and the date. The discussions are sorted by creation date (last modified) and the newest discussion is displayed first. The DiscussionLite channel view has links to view each discussion, view all discussions, and start a new discussion. All these links target the Discussions channel which gets displayed in the JSPDynamicSingleContainer.

Properties for this channel can be configured from the administration console. By default, there are no user editable properties for this channel.

Discussions Channel

The Discussions channel includes a full view that:

Shows detailed descriptions for the top eight discussions sorted in descending order. This can be reconfigured from the channel edit page.
Includes pagination so that users can see all the discussions.
Supports search. The search returns discussion and comment results.

Customizing the Discussion Channels

To Display Additional Fields in the List View of Discussions

Change directories to PortalServer-DataDir/portals/portal-ID/desktop/default/DiscussionProvider.

Modify query.jsp file and add xxx field to viewAttributes.

For example, add content-length as follows:

<search:setViewAttributes viewAttributes= "url,title,description,rd-rating,author,last-modified,rd-last-changed,rd-reference-id, rd-num-rating,rd-sum-rating,rd-peak-rating,rd-reference-url,htmldesc,content-length"/>

Add the new fields in fullDiscussionDisplay.jsp file wherever appropriate.

For example:
<search:getValue soifAttribute="content-length"/>

To Modify the Sort Order in List All Discussions Page

By default, discussions are sorted by the last-modified date/time. That is, discussions are displayed in a descending order with the latest or most recent discussion shown first.

To modify the sort order in list All Discussions page, modify the viewOrder property in fullDiscussion.jsp file. For example, you can reset the value below to author or rd-last-changed:
<jx:set var="viewOrder" value="-last-modified"/>

To Inherit Classification and `readACL`

If you have classified only the parent discussion manually or modified the access control for the parent discussion, you may want to inherit those values in discussion replies as follows:

Change directories to PortalServer-DataDir/portals/portal-ID/desktop/default/DiscussionProvider.

Edit feedbackProcess.jsp file and modify the values of inheritClassification and inheritReadACL.

By default, these are set to false. Reset them to true if you want comments to inherit the parent’s classification field and readACL field. Note that comments are automatically protected in this case.

Save the file.

Run the touch command.

For example, type touch *.jsp.

To Control Access to Discussions

This can be accomplished by one of the following two ways:

Modify the dbname property in the display profile for Discussions channel for each role to point to a different database.

In this case users in one role cannot view discussions created by users in a different role.

To Access Discussions Channel Directly

Type the following URL in your browser:

http://server:port/portal/dt?provider=JSPDynamicSingleContainer&JSPDynamicSingleContainer.selectedChannel=Discussions&last=false&action=content

Chapter 82 Configuring Surveys and Polls Portlets

This chapter describes about configuring surveys and polls portlets. This chapter contains the following sections:

Configuring Security for Surveys Portlet Datasource

For each service using a relational database, a separate database instance is configured with default userid and password. The default userid is portal and the default password is a random string generated during installation. Change the default password and the access permissions of the properties files containing the password.

To Change the Default Database Password

Restart Java DB.

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

Change the password for the default user, portal, by connecting to the surveysdb_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.authentication.provider',
 'BUILTIN');
CALL SYSCS_UTIL.SYSCS_SET_DATABASE_PROPERTY('derby.connection.requireAuthentication',
 'true');
CALL SYSCS_UTIL.SYSCS_SET_DATABASE_PROPERTY('derby.user.portal',
 'your-new-password');
CALL SYSCS_UTIL.SYSCS_SET_DATABASE_PROPERTY('derby.database.fullAccessUsers',
 'portal');
CALL SYSCS_UTIL.SYSCS_SET_DATABASE_PROPERTY('derby.database.defaultConnectionMode',
 'noAccess');

Restart Java DB.

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

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

For each portal instance:
1. Refer to the web container's documentation and set the password for the jdbc/SurveysDB datasource to the new password that was set in step 2.
2. Open the PortalServer-DataDir/portals/portal-ID/portletapps/surveys/tokens.properties file and change the password value for the DB_ADMIN_PASSWORD and DB_PASSWORD properties to the new password that you set in step 2.
3. Change the permissions for the PortalServer-DataDir/portals/portal-ID/portletapps/surveys/tokens.properties file so that it is readable and writable only by the owner.
  
  For example, type chmod 600 tokens.properties.
4. Restart the web container.

Configuring Tokens for Surveys and Polls Portlet

The Surveys and Polls portlets include the following tokens in the PortalServer-base/portletapps/surveys/tokens.properties file:

%DERBY_LIB_DIR%: Specifies the library where Java DB class files derbyclient.jar are located.
%DERBY_HOST%: Specifies the host server that host the Java DB.
%DERBY_PORT%: Specifies the port that the Java DB server host listens to for database requests.
%PORTAL_ID%: Specifies the Portal's ID.

Chapter 83 Installing and Configuring SharedEvents and SharedTasks Portlets

This chapter includes instructions for installing and configuring the SharedEvents and SharedTasks portlets manually after the Sun Java System Portal Server software installation.

Configuring Back-end Services for the Portlets

The SharedEvents and SharedTasks portlets in the Community Sample require certain back-end services to be setup and configured prior to installing and configuring the portlet. These back-end services are Sun Java^TM System Calendar Server and Sun Delegated Administration software. You can use an existing deployment or, choose to perform a fresh installation and configuration of these services. This section provides instructions for configuring the back-end services for these portlets.

The Calendar Server, Delegated Administration software, and Sun Java System Portal Server software must use the same Sun Java System Directory Server.

To Install and Configure the Back-end Services

See detailed documentation for Calendar Server and Delegated Administrator software for instructions on installing and configuring these software.

Documentation for:
- Installing and configuring Calendar Server is available at Part II, Post Installation Configuration for Calendar Server 6.3 Software, in Sun Java System Calendar Server 6.3 Administration Guide.
- Installing and configuring Delegated Administration software is available at Sun Java System Delegated Administrator 6.4 Administration Guide.

To Partition the Proxy Users in a Separate Organization

A proxy user is created for each community to manage that community's shared calendar. Follow the instructions in this section to avoid populating the manually created Portal Server users' organization.

Create a new parallel organization with a unique domain name to the organization containing the community users through Delegated Administration.

For example, create an organization called proxyusers.com.

Set the DA_DEFAULT_DOMAIN to the proxy user's newly created organization domain name.

For example, set the DA_DEFAULT_DOMAIN to proxyusers.com. If the portlets have already been deployed, update the relevant SSO adapters through the Portal Server management console and set the DA_DEFAULT_DOMAIN to the proxy users organization domain name.

Gathering Information for the Portlets

Before deploying the portlets, gather the following information:

UGRoot Suffix: This is the server/Group Root suffix of the Directory Server. This information is provided while running the commds_setup.pl script.
CSUGRoot Suffix: This is the UGRoot suffix under which the calendar users are created by default. It is under this suffix, the calendar admin user (calmaster) is created. It is important to choose this suffix appropriately such that the calendar admin user is able to proxy-authenticate other calendar users in other organizations. It is recommended that this suffix be the same as UGRoot Suffix. For the portlets, this specifies the value of Base Distinguished Node configuration input while configuring Calendar Server.
DA Default Domain: This is the DNS domain name of the default organization used by Delegated Administration software (for provisioning users by default). For the portlets, this specifies the value of Default Domain configuration input while configuring Delegated Administration software.
DA Default Organization DN: The Organization distinguished node will be the LDAP subtree under which all the users and groups that belong to the Delegated Administration software Default Domain are located. Note that the distinguished node must be located under the UGRoot Suffix. For the portlets, this specifies the value of Organization Distinguished Node for the Default domain configuration input while configuring Delegated Administration software.

Deploying the Portlets

To Install and Configure the Portlets

Before You Begin

Configure the back-end services and gather the required information.

Create the portlet WAR file.

To create the WAR file:

Note –
After Portal Server software has been installed, the portlet applications will be under the PortalServer-base/portletapps/portlet directory. If Portal Server has been configured, the portlet application will be in PortalServer-DataDir/portals/portal-ID/portletapps/portlet directory (where portlet refers to SharedEvents and SharedTasks portlets).
1. Edit the tokens.properties file to specify customizable parameters for the portlet.
  
  See Tokens for SharedEvents Portlet and Tokens for SharedTasks Portlet for more information.
2. Run ant customize.

Load SSO Adapter Template.

Change directories to PortalServer-DataDir/portals/portal-ID/portletapps/portlet/build/conf directory and type ant -f config.xml to load the SSO Adapter configuration.

Deploy the Portlets.
1. Create a file containing the password of the amadmin user. For example, type, echo mypassword >/tmp/ampasswd.
2. Type PortalServer-base/bin/psadmin deploy-portlet -u amadmin -f /tmp/ampassword -p portal-ID -i myInstance -g --userinfofile FULL-PATH-TO-userInfoMapping.properties FULL-PATH-TO-portlet.war-FILE.
3. Restart the container.

Add the Display Profile data to the templates.

The SharedEvents and SharedTasks portlets must be added to the Community templates to show up in new communities (created after the application has been installed). The template files are located at PortalServer-DataDir/portals/portal-ID/communitytemplates/ by default. The display profile is in the member.xml file in the template's directory.

For the portlets, do the following:

Remove the comment delimiters around the following lines to add your new channel to the available ones.

<Available>
....
<Reference value="%COMMUNITY_CONTAINER%/Sharedevents"/>
<Reference value="%COMMUNITY_CONTAINER%/Sharedtasks"/>
</Available>

Remove the comment delimiters around the following lines to add your new channel to the selected ones.

<Selected>
....
<Reference value="%COMMUNITY_CONTAINER%/Sharedevents"/>
<Reference value="%COMMUNITY_CONTAINER%/Sharedtasks"/>
</Selected>

Add availableDatabase in search channel.

To add, remove the comment delimiters around the following lines:

<Channel name="Search" provider="CommunitySearchProvider">
	<Properties>
		...
		 <String name="%COMMUNITY_SEARCH_DB_PREFIX%_sharedevents_%PORTAL_ID%.%COMMUNITY_ID%" 
		  value="Events"/>
		 <String name="%COMMUNITY_SEARCH_DB_PREFIX%_sharedtasks_%PORTAL_ID%.%COMMUNITY_ID%" 
		  value="Tasks"/>
		 ...
		</Collection>

Remove the comment delimiters around the following lines to add the channel definition.

For SharedEvents portlet:

<Channels>
....
<Channel name="Sharedevents" provider="__Portlet__sharedevents.sharedevents">
	<Properties>
		<String name="title" value="Community Calendar Events"/>
		<String name="description" value="Community Events Portlet"/>
		<String name="width" value="thick"/>
		<String name="__Portlet__ps.communityId" value="|DUMMY"/>
		<String name="__Portlet__community.calendar.config" value="|DUMMY"/>
		<String name="__Portlet__ps.searchserverurl" value="|%COMMUNITY_SEARCH_URL%"/>
		<String name="__Portlet__ps.searchdb" 
		 value="|%COMMUNITY_SEARCH_DB_PREFIX%_sharedevents_%PORTAL_ID%.%COMMUNITY_ID%"/>
		<String name="__Portlet__ps.visibleurl" 
		 value="?%COMMUNITY_CONTAINER%.setSelected=%COMMUNITY_CONTAINER%/Sharedevents"/>
		<Collection name="__Portlet__PreferenceProperties">
			<Collection name="default">
				<String name="ps.communityId" value="|DUMMY"/>
				<String name="community.calendar.config" value="|DUMMY"/>
				<String name="ps.searchserverurl" value="|%COMMUNITY_SEARCH_URL%"/>
				<String name="ps.searchdb" 
				 value="|%COMMUNITY_SEARCH_DB_PREFIX%_sharedevents_%PORTAL_ID%.%COMMUNITY_ID%"/>
				<String name="ps.visibleurl" 
				 value="?%COMMUNITY_CONTAINER%.setSelected=%COMMUNITY_CONTAINER%/Sharedevents"/>
			</Collection>
			<Collection name="isReadOnly">
				<Boolean name="ps.communityId" value="false"/>
				<Boolean name="community.calendar.config" value="false"/>
				<Boolean name="ps.searchserverurl" value="false"/>
				<Boolean name="ps.searchdb" value="false"/>
				<Boolean name="ps.visibleurl" value="false"/>
			</Collection>
		</Collection>
		<Collection  name="userInfoDescriptions">
			<Collection name="timezone">
				<String name="en-US" value="Preferred User Time Zone"/>
			</Collection>
		</Collection>
	</Properties>
</Channel>
</Channels>

For SharedTasks portlet:

<Channels>
....
<Channel name="Sharedtasks" provider="_Portlet__sharedtasks.sharedtasks">
	<Properties>
		<String name="title" value="Community Calendar Tasks"/>
		<String name="description" value="Community Tasks Portlet"/>
		<String name="width" value="thick"/>
		<String name="__Portlet__ps.communityId" value="|DUMMY"/>
		<String name="__Portlet__community.calendar.config" value="|DUMMY"/>
		<String name="__Portlet__ps.searchserverurl" value="|%COMMUNITY_SEARCH_URL%"/>
		<String name="__Portlet__ps.searchdb" 
		 value="|%COMMUNITY_SEARCH_DB_PREFIX%_sharedtasks_%PORTAL_ID%.%COMMUNITY_ID%"/>
		<String name="__Portlet__ps.visibleurl" 
		 value="?%COMMUNITY_CONTAINER%.setSelected=%COMMUNITY_CONTAINER%/Sharedtasks"/>
		<Collection name="__Portlet__PreferenceProperties">
			<Collection name="default">
				<String name="ps.communityId" value="|DUMMY"/>
				<String name="community.calendar.config" value="|DUMMY"/>
				<String name="ps.searchserverurl" value="|%COMMUNITY_SEARCH_URL%"/>
				<String name="ps.searchdb" 
				 value="|%COMMUNITY_SEARCH_DB_PREFIX%_sharedtasks_%PORTAL_ID%.%COMMUNITY_ID%"/>
				<String name="ps.visibleurl" 
				 value="?%COMMUNITY_CONTAINER%.setSelected=%COMMUNITY_CONTAINER%/Sharedtasks"/>
			</Collection>
			<Collection name="isReadOnly">
				<Boolean name="ps.communityId" value="false"/>
				<Boolean name="community.calendar.config" value="false"/>
				<Boolean name="ps.searchserverurl" value="false"/>
				<Boolean name="ps.searchdb" value="false"/>
				<Boolean name="ps.visibleurl" value="false"/>
			</Collection>
		</Collection>
		<Collection  name="userInfoDescriptions">
			<Collection name="timezone">
				<String name="en-US" value="Preferred User Time Zone"/>
			</Collection>
		</Collection>
	</Properties>
</Channel>
</Channels>

Add SharedEvents and SharedTasks as searchable databases in the CommunityPortlet.
1. Log in to Portal Server management console and select the portal where the portlets were deployed.
2. Choose a community enabled OrgDN (such as CommunitySample or DeveloperSample).
3. Select the Manage Container and Channels link and select the DP XML Tree view (from the View Type pull down list).
4. Click on the CommunityPortlet and add sharedevents and sharedtasks to the availableDatabases preference.

Restart the web container.

Login and verify that the service channel is displayed on your desktop.
1. Go to http://HOST:PORT/portal/dt and select Community Sample.
2. Login as test/test and create a new community. Then log out.
3. Re-login to the Community Sample portal as test/test.
  
  The SharedEvents and/or SharedTasks portlets are displayed.

Tokens for the Portlets

This section describes about the tokens that are required for portlets.

Tokens for SharedEvents Portlet

Shared Events defines the following tokens in the PortalServer-DataDir/portals/portal-ID/portletapps/sharedevents/tokens.properties file:

SSOADAPTER_TEMPLATE_NAME

Default value is CTY-SHARED-EVENTS.

Specifies the name of SSO Adapter name. This SSO Adapter contains the required configuration information for the portlet functioning. This SSO Adapter is per-portlet application; that is, the name should be different for each deployed portlet instance.

For example, HACKERS_COMMUNITY_EVENTS

SSOADAPTER_TEMPLATE_DESC

Default value is CTY-SHARED-EVENTS.

Contains the description for SSO Meta Adapter. This needs to be the same as SSOADAPTER_TEMPLATE_NAME for the template to be editable from the Access Manager console.

For example, HACKERS_COMMUNITY_EVENTS.

SSOADAPTER_ORGANIZATION_DN

Specifies the distinguished node of organization under which the SSO Adapter is loaded. The user retrieves the SSOAdapter from the Organization that the user belongs to.

For example, o=CommunitySample,dc=siroe,dc=example,dc=com.

DA_SERVER_HOST

Specifies the fully qualified name of the system where Delegated Administration server is running.

For example, daserver.blue.planet.com.

DA_SERVER_PORT

Default value is 80.

Specifies the port number of the Delegated Administration server.

For example, 80.

DA_DOMAIN_SEPARATOR

Default value is @.

Specifies the user ID and Domain Separater character.

For example, @.

DA_PROXY_ADMIN_USER_ID

Specifies the admin user for Delegated Administration that can be used to perform proxy authentication of users.

For example, admin.

DA_PROXY_ADMIN_USER_PASSWORD

Specifies the password for DA_ADMIN_USER_ID.

For example, abc123.

DA_DEFAULT_DOMAIN

Specifies the DNS Domain Name (sunPreferredDomain) of the organization where the CTY-PROXY-USER would be provisioned. The CTY-PROXY-USERs can be created in a different organization than the community users, in which case it should be manageable by Delegated Administrator.

For example, blue.planet.com.

IS_HOSTED_DOMAIN_ENV

Default value is false.

Specifies whether the portlet should use a hosted domains environment. For example, false

Note –

If the Delegated Administration server and Calendar Server are configured to use hosted domains setup, the value needs to be set to true.

AM_ADMINISTRATOR_DN

Specifies the distinguished name of the administrator for Sun Java System Access Manager software.

For example, uid=amAdmin,ou=People,dc=blue,dc=planet,dc=com

AM_ADMINISTRATOR_PASSWORD

Specifies the password for AM_ADMINISTRATOR_DN.

For example, abc123.

AMADMIN_COMMAND

Default value is /opt/SUNWam/bin/amadmin.

Specifies the fully qualified path name to the amadmin CLI of Access Manager.

For example, /opt/sun/am/bin/amadmin.

Tokens for SharedTasks Portlet

Shared Tasks defines the following tokens in the PortalServer-DataDir/portals/portal-ID/portletapps/sharedtasks/tokens.properties file:

SSOADAPTER_TEMPLATE_NAME

Default value is CTY-SHARED-TASKS.

For example, HACKERS_COMMUNITY_TASKS

SSOADAPTER_TEMPLATE_DESC

Default value is CTY-SHARED-TASKS.

Contains the description for SSO Meta Adapter. This needs to be the same as SSOADAPTER_TEMPLATE_NAME for the template to be editable from the management console.

For example, HACKERS_COMMUNITY_TASKS.

SSOADAPTER_ORGANIZATION_DN

Specifies the distinguished node of organization under which the SSO Adapter is loaded. The user retrieves the SSOAdapter from the Organization the user belongs to.

For example, o=CommunitySample,dc=siroe,dc=example,dc=com.

DA_SERVER_HOST

Specifies the fully qualified name of the system where Delegated Administration server is running.

For example, daserver.blue.planet.com.

DA_SERVER_PORT

Default value is 80.

Specifies the port number of the Delegated Administration server.

For example, 80.

DA_DOMAIN_SEPARATOR

Default value is @.

Specifies the user ID and Domain Separater character.

For example, @.

DA_PROXY_ADMIN_USER_ID

Specifies the admin user for Delegated Administration that can be used to perform proxy authentication of users.

For example, admin.

DA_PROXY_ADMIN_USER_PASSWORD

Specifies the password for DA_ADMIN_USER_ID.

For example, abc123.

DA_DEFAULT_DOMAIN

For example, blue.planet.com.

IS_HOSTED_DOMAIN_ENV

Default value is false.

Specifies whether the portlet should use a hosted domains environment.

For example, false

Note –

If the Delegated Administration server and Calendar Server are configured to use hosted domains setup, the value needs to be set to true.

AUTO_DELETE_CTY_PROXY_USER_CAL

Default value is false.

Specifies whether the portlet should delete the CTY-PROXY-USER when a community is deleted. The CTY-PROXY-USER is the community proxy user, a user created by the Shared Tasks portlet

For example, false.

CREATE_EVENTS_IN_CTY_MEMBERS_CAL

Default value is false.

Specifies whether the portlet should create the calendar task in all the member's community calendars whenever a community task is created.

For example, false.

AM_ADMINISTRATOR_DN

Specifies the distinguished name of the administrator for Sun Java System Access Manager software.

For example, uid=amAdmin,ou=People,dc=blue,dc=planet,dc=com

AM_ADMINISTRATOR_PASSWORD

Specifies the password for AM_ADMINISTRATOR_DN.

For example, abc123.

AMADMIN_COMMAND

Default value is /opt/SUNWam/bin/amadmin.

Specifies the fully qualified path name to the amadmin CLI of Access Manager.

For example, /opt/sun/am/bin/amadmin.

Chapter 84 Deploying and Configuring the Wiki Portlet

This chapter describes about deploying and configuring the Wiki portlet. This chapter contains the following sections:

Deploying the Wiki Portlet

This section includes instructions for deploying and editing the wiki portlet after Portal Server installation. After Portal Server is installed, portlets (available for deployment) are in the PortalServer-base/portletapps/portletname directory. If Portal Server has been configured, the portlet application will be in PortalServer-DataDir/portals/portal-ID/portletapps/portletapp directory. If Portal Server has not been configured, you must manually copy the files to the PortalServer-DataDir/portals/portal-ID/portletapps/portletapp directory before deploying the portlet.

To Deploy the Portlet

Log in to the Portal Server host and change directories to where the portlet application is located.

The wiki portlet is in the PortalServer-DataDir/portals/portal-ID/portletapps/wiki directory.

Create the portlet WAR file.

To create the WAR file:
1. Edit the tokens.properties file to specify customizable parameters for the portlet.
  
  See Tokens for Wiki Portlet for more information.
2. Run ant customize.
  
  Ensure that Java^TM DB is running before running ant.

Deploy the Portlets.

To deploy, type ant auto-deploy. You can run ant wikinodeploy to test your configuration before deploying the portlet. The ant wikinodeploy command will build the WAR file and configure the database, but will not deploy the portlet.

Log in and verify that the wiki portlet is deployed.
1. Go to http://HOST:PORT/portal/dt and select the sample where you deployed the wiki portlet.
2. Log in to the sample and view the portlet.

To Change the Default Password for the Database

For each portlet using a relational database, a separate database instance is configured with a default userid and password. The default userid is portal and the default password is a random string generated during installation. Change the default password and the access permissions of the properties files containing the password.

Restart Java DB.

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

Change the password for the default user, portal, by connecting to the wikidb_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.authentication.provider',
 'BUILTIN');
CALL SYSCS_UTIL.SYSCS_SET_DATABASE_PROPERTY('derby.connection.requireAuthentication',
 'true');
CALL SYSCS_UTIL.SYSCS_SET_DATABASE_PROPERTY('derby.user.portal',
 'your-new-password');
CALL SYSCS_UTIL.SYSCS_SET_DATABASE_PROPERTY('derby.database.fullAccessUsers',
 'portal');
CALL SYSCS_UTIL.SYSCS_SET_DATABASE_PROPERTY('derby.database.defaultConnectionMode',
 'noAccess');

Restart Java DB.

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

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

For each portal instance:
1. Refer to the web container's documentation and set the password for the jdbc/WikiDB datasource to the new password that was set in step 2.
2. Open the PortalServer-DataDir/portals/portal-ID/portletapps/wiki/tokens.properties file and change the password value for the DB_ADMIN_PASSWORD and DB_PASSWORD properties to the new password that you set in step 2.
3. Change the permissions for the PortalServer-DataDir/portals/portal-ID/portletapps/wiki/tokens.properties file so that it is readable and writable only by the owner.
  
  For example, type chmod 600 tokens.properties.
4. Restart the web container.

To Include Portlets on a Wiki Page

In order to display portlets on a wiki page, the wiki portlet must be the first selected element of a DynamicAggregationContainer. The display profile of the Developer Sample desktop and of the sample wiki community include such a container. The wiki portlet can display and aggregate other channels (or portlets) or aggregate provider and portlet channels that are in the available list of the DynamicAggregationContainer. If a channel is not in the available list, it will not appear on the page with no error or other indication. This allows the wiki portlet to include different channels for different users based on their display profiles. All portlets must be at the main wiki page in order to show the searched object from community home search results.

Interwiki Linking

Within a wiki, you can link to your own pages as well as pages in another wiki. Since each community gets its own wiki, you can link between communities this way. Each wiki is provisioned with its own set of initial pages. Linking between wikis is possible using links of the form [WikiName:PageName]. To link to another community's wiki, you must know the name of that community. For example, in the main page of the community X wiki, include the following:

X:Main
=======================
This is the main page of the community X wiki.
You can link to another page in X like this [SomePage]
You can also link to a page in a different wiki, eg, in communty Y,
like this [Y:Main] or [Y:SomePage]

Wiki permissions are tied to community membership and only members can edit a community wiki. The visitors can read community wiki pages if the community is not secure. By default, the community system currently disallows visitors any access to community content.

Configuring the Wiki Portlet

Portlet Preferences

The wiki portlet includes the following preferences that can be modified from the Portal Server management console or by editing the display profile template used when creating new communities in the PortalServer-dataDir/communitytemplates/wiki/ directory:

wikiTemplate: Specifies the name of the JSPWiki template used by this wiki portlet. The Portal Server software includes two of these templates: a full page template called wikicommunity and a rearranged version used by smaller wiki portlets called wikiportlet.
wikiPage: Specifies the name of the default wiki page for this wiki portlet
editorType: Specifies the type of editor used by this wiki portlet. Values can be text or html. A text wiki portlet uses a simple text editor, whereas an HTML wiki uses a WYSIWYG HTML editor.
editorOptions: Specifies the HTML editor plug-ins used in this wiki. This is specified only when editorType is html. Valid values are: PortletPicker, Stylist, CharacterMap, ContextMenu, FullScreen, ListType, SuperClean, TableOperations.
availablePortlets: Specifies the list of channel names (either portlets or provider channels) which this wiki portlet allows the user to select from when placing a channel on the page. Note that only channels in the corresponding DynamicAggregationContainer available list will actually be displayed. Typically, these two lists would contain the same channels.

Tokens for Wiki Portlet

The Wiki Portlet is based on JSPWiki. For more information on JSPWiki, see http://www.jspwiki.org. The Wiki Portlet supports the following configuration tokens in the PortalServer-DataDir/portals/portal-ID/portletapps/wiki/tokens.properties file:

WIKI_REPOSITORY_TYPE: Specifies the wiki page repository type, jdbc, for database (default) file for filesystem.
WIKI_WORK_DIR: Specifies the location of temp files and search index.
WIKI_FILESYSTEM_REPOSITORY_DIR: Specifies the location of filesystem repository (not used for JDBC repository).
WIKI_PAGE_TEMPLATES_DIR: Specifies the base location of the page template directories which are used to create the initial page sets of new wikis.
DB_ADMIN_URL, DB_ADMIN_USER, DB_ADMIN_PASSWORD, DB_ADMIN_DRIVER_CLASS, and DB_ADMIN_DRIVER_CLASSPATH: These are used by the system to create the wiki database repository when the wiki is first configured.
DB_JNDI_NAME and COMMUNITYMC_JNDI_NAME: These are used for the configuration of the wiki and community database resources.

The Wiki Portlet allows for the following runtime tokens in the PortalServer-DataDir/portals/portal-ID/portletapps/wiki/tokens.properties file:

jspwiki.applicationName

Specifies the default application name. It affects the HTML titles and logging, for example. It can be different from the actual web name (http://my.com/mywiki) of the application, but usually it is the same.

jspwiki.pageProvider

Specifies the provider class to use. For example, the values can be:

RCSFileProvider: For simple RCS-based file storage.
FileSystemProvider: For simple pure file storage with no version information.
VersioningFileProvider: For simple, non-RCS based versioning storage.

By default, this is set to JDBCPageProvider.

jspwiki.JDBCPageProvider.continuationEditMinutes

Specifies the minutes for editing the page before increasing the version of the page. Multiple edits by the same user within this interval will not increment the page version number and will appear as a single edit in the page history.

jspwiki.JDBCPageProvider.migrateFrom and jspwiki.JDBCAttachmentProvider.migrateFrom

Specifies the path to the properties files of the imported page and attachment repositories, which are used to build the initial database repository from default data, or to migrate from old versions of JSPWiki.

jspwiki.fileSystemProvider.pageDir

Specifies where wiki files are kept for FileSystemProvider and RCSFileProvider.

jspwiki.workDir

Specifies the JSPWiki working directory. The working directory is used to cache things like page reference data.

jspwiki.attachmentProvider

Specifies the attachment provider to use. You can specify BasicAttachmentProvider for a simple, flat file versioning provider or leave the value empty to disable the functionality. By default, this is set to JDBCAttachmentProvider.

jspwiki.basicAttachmentProvider.storageDir

If you specify the BasicAttachmentProvider as the attachment provider, this specifies where to store the files the user has uploaded.

jspwiki.baseURL

Specifies the base URL which can be used to rewrite all of JSPWiki's internal references.

jspwiki.auth.useOldAuth

Enables authorization. Authorization for community wiki is based on community membership.

jspwiki.translatorReader.allowHTML

Specifies whether raw HTML is allowed as Wiki input. By default, this is set to true. You can also specify yes or no, or on or off.

jspwiki.templateDir

Specifies the default template used by the Wiki engine. The templates live in wiki-webapp-location/templates/template-name directory. JSPWiki will attempt to find two basic templates (ViewTemplate and EditTemplate) from that directory. The default JSPWiki template is called default which is provided as a reference only. The wiki portlet uses templates called wikicommunity and wikiportlet.

jspwiki.lockExpiryTime

Specifies the number of minutes a person can lock a page while editing it.

jspwiki.searchProvider, jspwiki.searchServer, and jspwiki.searchDatabase

Specifies search server configuration information.

jspwiki.pageTemplatesConfigDir

Specifies a file system directory containing wiki page template configurations. A wiki page template defines a set of initial pages used when a new wiki is created. Wiki channels specify the page template with the wikiTemplate property. There are currently three templates:

default: Used by the wiki tab and wiki portlets in the Developer Sample portal.
community: Used by wiki communities.
communityportlet: Used by wiki portlets in the community framework.

log4j.logLevel

Specifies the logging level.

log4j.appender.FileLog.File

Specifies the log file location. The default log location is dynamically set to PortalServer-DataDir/logs/instance-name/jspwiki.log.

Previous: Part X File Formats

Part XI Service Providers and Portlets

Chapter 77 Service Providers

Overview of the Service Providers

Search Provider

Discussion Provider

Chapter 78 Portlet Application Framework

Overview of the Framework

Ant Targets

Installing the Portlet Application

Example 78–1 Reconfiguring the File Sharing Portlet Application

Chapter 79 Overview of the Community Services

Community Services

Chapter 80 Search Provider

Overview of Customizing the Search Provider

Search Provider Design

Search JavaServer Pages and Tag Libraries

Example 80–1 JSP Layout for searchContent.jsp

Debugging the Search Providers

Customizing the Search Provider

To Add last-modified to the Search Result Display

To Remove content-length from Search Results

To Remove Author From the Advanced Search Interface

To Add a New Field to Advanced Search

To Access Search Channel Directly

Chapter 81 Discussion Provider

Overview of Customizing the Discussion Provider

Discussion Service Channels

DiscussionLite Channel

Discussions Channel

Customizing the Discussion Channels

To Display Additional Fields in the List View of Discussions

To Modify the Sort Order in List All Discussions Page

To Inherit Classification and readACL

To Control Access to Discussions

To Access Discussions Channel Directly

Chapter 82 Configuring Surveys and Polls Portlets

Configuring Security for Surveys Portlet Datasource

To Change the Default Database Password

Configuring Tokens for Surveys and Polls Portlet

Chapter 83 Installing and Configuring SharedEvents and SharedTasks Portlets

Configuring Back-end Services for the Portlets

To Install and Configure the Back-end Services

To Partition the Proxy Users in a Separate Organization

Gathering Information for the Portlets

Deploying the Portlets

To Install and Configure the Portlets

Before You Begin

Tokens for the Portlets

Tokens for SharedEvents Portlet

Tokens for SharedTasks Portlet

Chapter 84 Deploying and Configuring the Wiki Portlet

Deploying the Wiki Portlet

To Deploy the Portlet

To Change the Default Password for the Database

To Include Portlets on a Wiki Page

Interwiki Linking

Configuring the Wiki Portlet

Portlet Preferences

Tokens for Wiki Portlet

Example 80–1 JSP Layout for `searchContent.jsp`

To Inherit Classification and `readACL`