Page Comparison

...

<properties>
    	<!-- Dependency versions -->
    	<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 the latest version as of this writing, 1.0.9, 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.9<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

...

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>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.Change it to

<!--
  AdminisrativeAdministrative role mappingdeclaration.
 This mappingUsers isin requiredthis ifrole youcan administer the wantdefault tocalendars usein the administrative features.
 -->
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>
  <role</security-link>Administrator</role-link>ref>


  </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":

<!--
  Adminisrative role mapping.  This mapping is required if you
  want to use the administrative features.
 --> 
  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>calendarAdmin<name>everyone</role-name>
  <role-link>calendarAdmin</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.

...

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:

<?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>
        <private-request-attributes>true</private-request-attributes>
    </portlet>

    <role-mapper>
        <role-name>calendarAdmin</role-name>
        <role-link>Administrator</role-link>
    </role-mapper>
    <role-mapper>
        <role-name>everyone</role-name>
        <role-link>User</role-link>
    </role-mapper>
    
</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.

...

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.

...

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.

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>