Page Comparison

...

<script type="text/javascript" src="<rs:resourceURL value="/rs/fluid/10.8.1.2/js/fluid-all-1.1.2.min.js"/>"></script>

...

This portlet depends on the Fluid Skinning System (fss). Alas, Liferay 5.2 SP3 doesn't make the Fluid Skinning System CSS available, and the Resource Server version in the trunk of the portlet doesn't either, so this portlet needs to be modified to explicitly include these files.

In order for it to be able to reference these CSS files, the fss files must be included in the portlet-local resources directory.

Step 1:

...

• Navigate to and open the css.jsp file. This file is located in the Calendar portlet.
  • Source Location: CalendarPortlet/trunk/src/main/webapp/WEB-INF/jsp/css.jsp
• Add the code snippet depicted in figure 1 to your css.jsp file. 

...

Update dependency on Resource Server to get a later version

In pom.xml, update this:

<properties>
    	<!-- INSTRUCTIONSDependency |versions The-->
below code snippet should be placed just below the include.jsp directive
| and above the tag that links to the calendar.css file.
-->
<c:set var="RESOURCE"><rs:resourceURL value="/rs"/></c:set>
<link rel="stylesheet" href="${RESOURCE}/fluid/1.1.2/fss/css/fss-layout.css" type="text/css"></link>
<link rel="stylesheet" href="${RESOURCE}/fluid/1.1.2/fss/css/fss-text.css" type="text/css"></link>

...

Step 2: Place fluid css resources in rs directory.

• Download the Fluid Skinning System (FSS) css files. For the latest version of FSS please see the Fluid Project and download Fluid Infusion.
• Once downloaded, extract the calendar_portlet_fss.zip file.
• The calendar_portlet_fss.zip file extracts to the fss directory.

...

Map roles

Enable Calendar Administration

You only need to enable calendar administration if you want some adminstrative users to be able to administer this portlet through its UI, e.g. to define default calendar configurations and their audiences. The simplest use cases of simply allowing users to add iCal feeds of their choice in the portlet do not require this administrative capability.

The Calendar Portlet uses the JSR-168 API isUserInRole() to determine whether the presently accessing user is an administrator. You'll need to map the calendar portlet's name for an administrator role to an existing or new Liferay role.

...

 	<cas.version>3.1.8</cas.version>
    	<hsqldb.version>1.8.0.7</hsqldb.version>
    	<resource-server.version>1.0.5</resource-server.version>

to declare version 1.0.6 of resource-server, rather than the 1.0.5 there currently.

<properties>
    	<!-- Dependency versions -->
    	<cas.version>3.1.8</cas.version>
    	<hsqldb.version>1.8.0.7</hsqldb.version>
    	<resource-server.version>1.0.6</resource-server.version>

You might be tempted to upgrade all the way to version 1.0.9, which is a good idea, but requires an additional exclusion to avoid conflicting Spring Framework versions in underlying dependencies.

(TODO: Document using version 1.0.9 and the necessary exclusion.)

Step 2: Use the Fluid Skinning System that will now be available

• Navigate to and open the css.jsp file. This file is located in the Calendar portlet.
  • Source Location: CalendarPortlet/trunk/src/main/webapp/WEB-INF/jsp/css.jsp

Before:

<jsp:directive.include file="/WEB-INF/jsp/include.jsp"/>
<link rel="stylesheet" href="<c:url value="/css/calendar.css"/>" type="text/css"></link>

After:

<!--
  Adminisrative role mapping.  This mapping is required if you
  want to use the administrative features.
 -->
<security-role-ref>
  <role-name>calendarAdmin</role-name>
  <role-link>local.2</role-link>
</security-role-ref>

Option 1: Mapping to the existin Liferay portal administrator role for administering the calendar portlet

The simplest solution is to map to the existing Liferay administrator role.

...

<!--
  Adminisrative role mapping.  This mapping is required if you
  want to use the administrative features.
 -->
<security-role-ref>
  <role-name>calendarAdmin</role-name>
  <role-link>Administrator</role-link>
</security-role-ref>

Option 2: Creating and mapping to a new Liferay role for administering the calendar portlet

Another solution is to create a role explicitly for this privilege of administering the calendar portlet. You'd take this route if the set of users who should be able to administer the calendar portlet is different from the set of users who should have administration capabilities over the entire portal.

This mapping tells the portlet and Liferay that the relevant Liferay role will be called "calendarAdmin":

<jsp:directive.include file="/WEB-INF/jsp/include.jsp"/>

<!-- added for Liferay 5.2 SP3 compatibility -->
<c:set var="RESOURCE"><rs:resourceURL value="/rs"/></c:set>
<link rel="stylesheet" href="${RESOURCE}/fluid/1.1.2/fss/css/fss-layout.css" type="text/css"></link>
<link rel="stylesheet" href="${RESOURCE}/fluid/1.1.2/fss/css/fss-text.css" type="text/css"></link>

<link rel="stylesheet" href="<c:url value="/css/calendar.css"/>" type="text/css"></link>

Map roles

Enable Calendar Administration

You only need to enable calendar administration if you want some adminstrative users to be able to administer this portlet through its UI, e.g. to define default calendar configurations and their audiences. The simplest use cases of simply allowing users to add iCal feeds of their choice in the portlet do not require this administrative capability.

The Calendar Portlet uses the JSR-168 API isUserInRole() to determine whether the presently accessing user is an administrator. You'll need to map the calendar portlet's name for an administrator role to an existing or new Liferay role.

In portlet.xml you'll find this:

<!--
  Adminisrative role mapping.  This mapping is required if you
  want to use the administrative features.
 -->
<security-role-ref>
  <role-name>calendarAdmin</role-name>
  <role-link>calendarAdmin<link>local.2</role-link>
</security-role-ref>

Of course, the role "calendarAdmin" does not exist in out of the box Liferay 5.2 SP3. You'll need to add it.

As a sufficiently privileged user in Liferay, access the Control Panel. Under Portal, select Roles. Click Add. Name your new role "calendarAdmin", give it a description if you like. The type of role is a bit complicated – for the simplest use cases, leave this as "Regular" (a universal, portal-wide role). Click "Save" to persist your new role.

Notice your new role in the list of roles that you see after saving. Click Actions->Assign Members for this new "calendarAdmin" role and add users and groups to this role who ought to be able to administer the calendar portlet.

Once you've added users to this role and configured the portlet to map its calendarAdmin checking to that role via portlet.xml (the steps described above), sufficiently privileged users should start seeing a "Calendar Administration" link in the wider focused view of the portlet. This will allow administrators to e.g. configure default calendars to appear to some users.

Enable calendar audience targeting

Part of the point of being a calendar portlet administrator is to be able to define calendar configurations that are experienced by some users. That "some users" bit is also defined by an isUserInRole() check and a role. In portlet.xml, you can see several other default roles listedChange it to

<!--
  Administrative role declaration.
  Users in this role can administer the default calendars in the portlet
  via an in-portlet UI.
  This role is declared here and is mapped in liferay-portlet.xml.
  -->
  <security-role-ref>
    <role-name>calendarAdmin</role-name>
  </security-role-ref>


  <!-- 
  Additional roles for assigning default calendars.  Any roles
  you wish to use must be declared here.  They are mapped to Liferay roles in
  liferay-portlet.xml 
  -->
  <security-role-ref>
    <role-name>everyone</role-name>
  </security-role-ref>

Option 1: Mapping to the existing Liferay portal administrator role for administering the calendar portlet

The simplest solution is to map this "calendarAdmin" JSR-168 role in the portlet to the existing Liferay administrator role.

For portlets for use with Liferay, you put this mapping in liferay-portlet.xml alongside the existing portlet.xml. Add a liferay-portlet.xml with this content:

 <!-- 
            Additional roles for assigning default calendars.  Any roles
  ?xml version="1.0"?>
<!DOCTYPE liferay-portlet-app PUBLIC "-//Liferay//DTD Portlet Application 4.2.0//EN" "http://www.liferay.com/dtd/liferay-portlet-app_4_2_0.dtd">
<liferay-portlet-app>
    <portlet>
        <portlet-name>calendar</portlet-name>
         you wish to use must be assigned keys here. <private-request-attributes>true</private-request-attributes>
    </portlet>

    <role-mapper>
        <role-name>calendarAdmin</role->name>
        <security-role-ref><role-link>Administrator</role-link>
    </role-mapper>
    <role-mapper>
        <role-name>everyone</role-name>
            <role-link>local.0<<role-link>User</role-link>

       </security-role-ref>mapper>
    
   <security-role-ref>
            <role-name>student</role-name>
            <role-link>local.1</role-link>
 </liferay-portlet-app>

Option 2: Creating and mapping to a new Liferay role for administering the calendar portlet

Another solution is to create a role explicitly for this privilege of administering the calendar portlet. You'd take this route if the set of users who should be able to administer the calendar portlet is different from the set of users who should have administration capabilities over the entire portal.

This mapping (in liferay-portlet.xml) tells the portlet that the relevant Liferay role will be called "calendarAdmin":

<!--
  Administrative role mapping.  This mapping is required if you
  want to use the administrative features.
 -->
<role-mapper>
  <role-name>calendarAdmin</role-name>
  <role-link>calendarAdmin</role-link>
<role-mapper>

Of course, the role "calendarAdmin" does not exist in out of the box Liferay 5.2 SP3. You'll need to add it.

As a sufficiently privileged user in Liferay, access the Control Panel. Under Portal, select Roles. Click Add. Name your new role "calendarAdmin", give it a description if you like. The type of role is a bit complicated – for the simplest use cases, leave this as "Regular" (a universal, portal-wide role). Click "Save" to persist your new role.

Notice your new role in the list of roles that you see after saving. Click Actions->Assign Members for this new "calendarAdmin" role and add users and groups to this role who ought to be able to administer the calendar portlet.

Once you've added users to this role and configured the portlet to map its calendarAdmin checking to that role via portlet.xml (the steps described above), sufficiently privileged users should start seeing a "Calendar Administration" link in the wider focused view of the portlet. This will allow administrators to e.g. configure default calendars to appear to some users.

Enable calendar audience targeting

Part of the point of being a calendar portlet administrator is to be able to define calendar configurations that are experienced by some users. That "some users" bit is also defined by an isUserInRole() check and a role. In portlet.xml, you can see several other default roles listed:

 <!-- 
            Additional roles for assigning default calendars.  Any roles
            you wish to use must be assigned keys here. 
        -->
        <security-role-ref>
            <role-name>everyone</role-name>
            <role-link>local.0</role-link>
        </security-role-ref>
        <security-role-ref>
            <role-name>student</role-name>
            <role-link>local.1</role-link>
        </security-role-ref>
        <security-role-ref>
            <role-name>faculty</role-name>
            <role-link>local.2</role-link>
        </security-role-ref>
        <security-role-ref>
            <role-name>staff</role-name>
            <role-link>local.3</role-link>
        </security-role-ref>

...

In Liferay, you'd define the membership of that role to be those users that you expect to have Blackboard accounts (ultimately fulfilling the role with membership in a community or a group that's e.g. synced in from LDAP, since you presumably don't want to be manually adding users to this role).

You might also create an Everyone role and map it to the Users role in Liferay (all authenticated users) if you want to reach all logged in users. And so on.

...

or a group that's e.g. synced in from LDAP, since you presumably don't want to be manually adding users to this role).

You might also create an Everyone role and map it to the Users role in Liferay (all authenticated users) if you want to reach all logged in users. And so on.

In portlet.xml:

 <!-- 
            Additional roles for assigning default calendars.  Any roles
            you wish to use must be assigned keys here. 
        -->
        <security-role-ref>
    Additional roles for assigning default calendars.  Any roles <role-name>everyone</role-name>
        </security-role-ref>
   you wish to use must be<security-role-ref>
assigned keys here.          <role-name>usersWithBlackboardAccounts</role->name>
         <security</security-role-ref>

And in liferay-portlet.xml:

    <role-mapper>
        <role-name>everyone</role-name>
 
          <role-link>Users<link>User</role-link>
   
    </security-role-ref>mapper>
        <security-role-ref><role-mapper>
            <role-name>usersWithBlackboardAccounts</role-name>
            <role-link>usersWithBlackboardAccounts</role-link>name>
        </security-role-ref>mapper>