[PLUTO-680] TCK: Contesting tests that reference Pluto-specific security roles

• Type: Bug
• Status: Closed
• Priority: Major
• Resolution: Fixed
• Affects Version/s: 3.0.0
• Fix Version/s: 3.0.1
• Component/s: tck
• Assignee: Neil Griffin (Inactive)
• Reporter: Dante Wang
• Created: 12/Jan/18 06:55
• Updated: 14/Dec/22 14:37
• Resolved: 03/May/18 13:07

Description

TCK test cases

• V2RequestTests_PortletRequest_ApiEvent_isUserInRole1
• V2RequestTests_PortletRequest_ApiResource_isUserInRole1
• V3HeaderPortletTests_SPEC14_PortletRequest_ApiHeader_isUserInRole1
• AnnotationPortletConfigTests_SPEC2_28_SecurityRole

test the requirement "Method isUserInRole(): returns true if the authenticated user is in the specified role" as specified in Portlet Spec 3.0 Chapter 24.2, 24.3, and JavaDoc.

The test cases perform the tests by doing the following check:

boolean usrole=portletReq.isUserInRole("pluto");

if(usrole==true) {
   tr46.setTcSuccess(true);
} else {
   tr46.appendTcDetail("The Authenticated user is not in Specified Role");
}

The problem is, the role used in the test case is Pluto specific, while other portal vendors may use complete different role names. For example, there's no role named "pluto" in Liferay, so the test cases fail in Liferay.

The proposed solution is to use a Maven profile that contains a property with a role name that is unique to each portal vendor.