liferay-ui:discussion returns No Permission Error

[旻 吴, modificado hace 2 meses.]

Hello everyone. I am facing a problem that liferay-ui:discussion always gives No Permission return when a user assigned with only site roles is trying to add a new comment. This problem is relating to another one: This. I found that if I remove "formAction" parameter from liferay-ui:discussion section, the contentURL of notification will be correct. But after removing 'formAction', the problem described in this thread occurs.

In details, we have a customized model called CustomizedModel, and in its view page, there is a discussion list:

<liferay-ui:panel collapsible="<%= true %>" extended="<%= true %>" persiststate="<%= true %>" title="Comment:">
	
	<portlet:actionurl name="invokeTaglibDiscussion" var="discussionURL" />

	<liferay-ui:discussion className="<%= CustomziedModel.class.getName() %>" classPK="<%= customizedModel.getModelId() %>" formName="fm2" ratingsEnabled="false" redirect="<%= currentURL %>" userId="<%= customizedModel.getUserId() %>" />
</liferay-ui:panel>

The default permission for SITE MEMBER is ADD_DISCUSSION only. VIEW is used for access control. Now we set a customziedModel M's permissions as : SITE MEMBER: VIEW, ADD_DISCUSSION, and let a user A assigned with only SITE MEMBER role to try to create a new comment, the discussion taglib will returns:

"{"exception":"class com.liferay.portal.kernel.security.auth.PrincipalException$MustHavePermission:User 0 must have ADD_DISCUSSION permission for test.customized.model.CustomizedModel 28972"}"

But if we use

	<%
		DiscussionPermission dp = CommentManagerUtil.getDiscussionPermission(
				themeDisplay.getPermissionChecker());
		_log.info(dp.hasAddPermission(
					themeDisplay.getCompanyId(), 
					themeDisplay.getScopeGroupId(),
					CustomziedModel.class.getName(), 
					CustomziedModel.getModelId()
					));
	%>

just before liferay-ui:discussion in view jsp to check the permission( the codes should be just the same with thoes in EditDiscussionStrutsAction.java, the default formAction processor of liferay-ui:discussion), it returns TRUE.

Furthermore, it can be noticed that this problem only occurs with SITE ROLES. If ADD_DISCUSSION is assigned to USER role, every thing works well. If we create a general role called TESTROLE, assign user A to it and assign ADD_DISCUSSION of customizedModel M to it, everything works well.

Would anyone tell me what is going wrong here? I was completely lost. Thank you so much.

[Andrew Jardine, modificado hace 6 años.]

The thing that immediately caught my eye is

n$MustHavePermission:User 0

mostly because User with id 0 is the Guest (anonymous) user so they definitely would not have permission to post. Looking at some of the code you added, I am wondering about this one --

<liferay-ui:discussion className="<%= CustomziedModel.class.getName() %>" classPK="<%= customizedModel.getModelId() %>" formName="fm2" ratingsEnabled="false" redirect="<%= currentURL %>" userId="<%= customizedModel.getUserId() %>" />

What made you decide to use userId="<%= customizedModel.getUserId() %>"? I would have expected the userId value to be the ID of the user currently on the page. Can you double check to see if that code produces a value of 0?

I say this because when you do the permissions check, you don't pass that userId. The PermissionThreadLocal would contain a reference to your user id so it saying that you have access to perform the action would be correct because it is checking a logged in Site Member, which I am guessing is not the same as the customizedModel.getUserId()?

[旻 吴, modificado hace 2 meses.]

Hello Andrew Jardine, thank you very much for your response. Actually this is what I very first checked. I tried <%= themeDisplay.getUserId() %> but it didn't work.

Indeed I have no idea about why customizedModel.userId() is used: just because liferay source code is using this approach, such as

Document library: view_file_entry.jsp

<liferay-comment:discussion className="<%= dlViewFileVersionDisplayContext.getDiscussionClassName() %>" classPK="<%= dlViewFileVersionDisplayContext.getDiscussionClassPK() %>" formName="fm2" ratingsEnabled="<%= dlPortletInstanceSettings.isEnableCommentRatings() %>" redirect="<%= currentURL %>" userId="<%= fileEntry.getUserId() %>" />

[Andrew Jardine, modificado hace 6 años.]

Fair enough -- Liferay's source is often the example I follow for my own work as well, so I would say that your approach is sound.

Can you check to see what the value being placed in there is though? is it a 0?

[旻 吴, modificado hace 2 meses.]

No, it is not 0 but the creator's Id of the customizedModel.

[旻 吴, modificado hace 2 meses.]

Finally I got the cause of the problem:

If ADD_DISCUSSION + UPDATE_DISCUSSION is defined for the CustomziedModel and the site-member has default ADD_DISCUSSION, problem occurs.

If there is no ADD_DISCUSSION defined, site-member has default UPDATE_DISCUSSION, every thing works well.

[Andrew Jardine, modificado hace 6 años.]

I thought you have mentioned that you had already checked the site role permissions. At any rate, glad you found the issue, and thanks for sharing with us. I'll be sure to keep that one in the archives in case I ever come across the same issue.

[旻 吴, modificado hace 2 meses.]

Here we have some updates.

If the discussion page is on a customized site and a user A is assigned with that site, problem occurs. But if the user is assigned as the site-member of BOTH the customized site AND the liferay default DXP site, it works. I wonder if liferay's SITE-MEMBER role id is varying between different sites?

BTW, the permission checker of discussion permission will throws:

		if (!hasAddPermission(companyId, groupId, className, classPK)) {
			throw new PrincipalException.MustHavePermission(
				0, className, classPK, ActionKeys.ADD_DISCUSSION);
		}

therefore user 0 is nothing else other than a place holder.

[Andrew Jardine, modificado hace 6 años.]

Hmm -- I'd be surprised. The Site Member role exists at the company level, so I could only see the id changing if your sites were in different companies. But in that case, there would be a whole world of difference, so I doubt that is it.

[旻 吴, modificado hace 2 meses.]

Another update:

旻 吴:

If the discussion page is on a customized site and a user A is assigned with that site, problem occurs. But if the user is assigned as the site-member of BOTH the customized site AND the liferay default DXP site, it works.

The reason of the quoted words is, when the discussion publishing process calls the

BaseModelPermissionChecker
    .checkBaseModel(PermissionChecker permissionChecker, long groupId, long primaryKey, String actionId)

the groupId is indeed 20143, not the site on which liferay-ui:discussion is allocated. Therefore if the user is assgined with the default DXP site
( its scopegroupid is 20143 ), add discussion will success because the groupid is correct.

For the same reason, one should always write:

@Override
public void checkBaseModel(PermissionChecker permissionChecker, long groupId, long primaryKey, String actionId)
			throws PortalException {
	check(permissionChecker, primaryKey, actionId);
}

and pass the groupId of the model to permission checker's logic rather than use the groupId passed into directly:

@Override
public void checkBaseModel(PermissionChecker permissionChecker, long groupId, long primaryKey, String actionId)
			throws PortalException {
	// Wrong way:
	check(permissionChecker, groupId, primaryKey, actionId);
}

It is rather a pity that there are so many similar traps without either explanation nor document in liferay's source codes.

[旻 吴, modificado hace 2 meses.]

Finally we got the cause: our ModelPermissionChecker is not registered as an OSGI component. So it seems that discussionpermission checker can not find the model permissionchecker to check ADD_DISCUSSION permission.

And the reason we haven't got the point for a long time is, the ModelPermissionChecker was written in early September, almost following the official tutorial. However, the codes of the official tutorial at that time was incorrect. The correct codes were uploaded in September 29 when we were developing other utilitlies. Lines from 96 to 104 will tell the story.

https://github.com/liferay/liferay-docs/commit/161566774ccad8a609675522b3cd0834929270e8

By the way, it is still a mystery that,

(No model permission checker) or ( model permission checker is not registerd as an OSGI component)
+
( no ADD_DISCUSSION is defined)
= works quite well. One can add new comment or modify its own comment without any problem.

But
+
( ADD_DISCUSSION, UPDATE_DISCUSSION , DELETE_DISCUSSION is defined)
= the title of this thread

[Andrew Jardine, modificado hace 6 años.]

Glad you got it resolved. I recently had a similar experience with one of the guides from the developer site. In my case perhaps it was a little more obvious because what I was trying to do completely failed. In the end for me I referenced the same feature that was already done by Liferay .. Most of the time I use their Liferay source as my guide. It might not provide a wordy explanation, but it at least provides the blue print for what to do.

[Jack Bakker, modificado hace 6 años.]

Andrew Jardine:

.. Most of the time I use their Liferay source as my guide. It might not provide a wordy explanation, but it at least provides the blue print for what to do.

Perhaps I am hijacking this thread, but Andrew: where can developers go to learn more about how best to quickly dig Liferay source in their IDE of choice (IntelliJ, Eclipse, or ...). I can't look in the source for that...

[旻 吴, modificado hace 2 meses.]

Fully agree with it. This story taught me a lesson that following the source codes is ways better than following any other things.