3
votes

I am very new to liferay 7 ,actually we are migrating liferay 6.2 to liferay-7 ,in the 6.2 we are using ext to override the action class but in the liferay-7 I am getting some cofusion,could you please help me out.

The main theme of my ext is : whenever a new role getting created in an organization from the control panel, we need to store the role information and organization information in our custom table for that we have overriden EditRoleAction.java in LR6.2 so same thing we are trying to achieve in LR7.

Action class in Liferay 6.2 :

Portal path : D:\Liferay6.2workspace\portal\portal-impl\src\com\liferay\portlet\rolesadmin\action\EditRoleAction.java

Ext Path: CutomRoles-ext/docroot/WEB-INF/ext-impl/src/com/liferay/portlet/rolesadmin/action/EditRoleAction.java

Action class in Liferay 7.0GA4 :

D:\Liferay7GA4\portal\modules\apps\foundation\roles\roles-admin-web\src\main\java\com\liferay\roles\admin\web\internal\portlet*RolesAdminPortlet.java*

1
we're here to "help out", however you only describe some files, but not what you actually want to achieve. What are you doing in the overridden action - or are you adding a new action? Please describe in code- as well as in business terms (don't comment with those details, rather edit your question)Olaf Kock
Hello @OlafKock could you please check the updated questionPVBRaju

1 Answers

0
votes

It really sounds like overriding the Action is not the right place to go. Look up ServiceWrappers - these will run on the business layer, and you can add additional code to (from memory) RoleLocalService.addRole(...) and other related methods.

Ext was never necessary for this purpose and shouldn't have been used in the first place. In fact, with the use of ext you deliberately make maintenance and upgrades a lot harder than when you go the regular plugin route. And with Liferay 7 and DXP the use of ext should be the extremely rare absolute exception to the rule. In fact, it's just now being reintroduced after being absent so far (because in a few rare exceptional cases it's still the only way). However, it's safe to assume that you don't need it.

Now that the description in the comments to this answer goes much further than the description in the question: You might need some portlet-level customizations as well. For this: Identify where the portlet is currently implemented (e.g. identify the module) and override its actions (there's a good chance that this article can help) and potentially also the UI.

And yet another alternative: You might be able to achieve the same by using Teams in the organization's site: They behave almost like roles but are only available to a single site (no organization though, but you state that your organizations have sites anyway)