How to implement ext plugin of portal-kernel?

[Jan Beran, geändert vor 6 Jahren.]

Hello

I am currently trying to implemet an ext-plugin to extend the WorkflowConstans.java (to add new workflow statuses). I have created an ext-plugin in Eclipse, overwote the code of the java file and deployed to the server. But the changes did not take effect - there are no new workflow statuses to be used. Therefore, there goes my question:

1) The WorkflowConstants.java is part of the portal-kernel. In the ext-plugin folder structure, where should it be placed? There are conflicting sources claiming whether it should be ext-impl/src or ext-service/src

2) Is it enough to just paste the java file into the directory structure of the plugin, make changes to the code and drag & drop it into the portal instance? Or do I have to do something else for the changes to take effect, like changing the portlet-ext.xml?

Thanks for any advice.

I am using Liferay 6.2 CE GA6 bundled with Tomcat and Eclipse Neon 3 with Liferay IDE 3

[David H Nebinger, geändert vor 6 Jahren.]

Seems like this might be a huge change. You can't just start throwing new workflow statuses in there and expect the portal to function, workflow is a state machine that, if you introduce unknown states, will likely break the machine.

Perhaps you can share what you need to do and we might offer a better path?







Come meet me at the 2017 LSNA!

[Jan Beran, geändert vor 6 Jahren.]

Hi David

Thanks for your reply. What I am trying to accomplish is to introduce new workflow statuses to the workflow engine, other than the default 8. The way of the ext-plugin is already described here, but my plugin fails to have effect. If I try to assign the new status using the javascriptscript, the status label displayed is "Any".

But if you know of a better way how to achieve the desired result, I'd also like to hear about that .

Regards,

Jan

[David H Nebinger, geändert vor 6 Jahren.]

What kind of status are you trying to add?

I'm wondering if it is perhaps not a workflow status as much as it is some kind of entity status?







Come meet me at the 2017 LSNA!

[Jan Beran, geändert vor 6 Jahren.]

OOB, Liferay offers workflow statuses like "Pending", "Denied" or "Approved". I would also need to indicate other WF statuses, like e.g. "Manager approved", "Files uploaded" and such.

I am not sure I get what you mean by entity status.

Thanks,

Jan

[David H Nebinger, geändert vor 6 Jahren.]

So normal Liferay workflow for, say, a web content might be PENDING -> APPROVED, and there are points in a lot of the Liferay code that knows when to include or exclude PENDING, how to handle transition, "still pending" notifications, ...

I get that you may want to do something like PENDING -> MGR APPROVED -> APPROVED as a result of multiple-approver workflow.

So when I suggest this is an "entity status", MGR APPROVED from Liferay's workflow engine perspective is exactly the same as PENDING, meaning it is not really approved and all of the normal PENDING logic actually should be applied. The fact that it is only MGR APPROVED and not the final APPROVED is an entity status, and not a workflow status.

This kind of highlights why I was concerned about adding status values; if you were able to add MGR APPROVED, all normal Liferay processes grind to a halt. The normal PENDING logic wouldn't fire because it is not PENDING, for example.

If I wanted to implement something like this, I'd be tracking a separate state either in my custom entity or as an expando for a Liferay entity. That way as the entity transitions through your workflow, you could update the entity status separately from real workflow status. You can display the custom entity status where you need to, but the default Liferay workflow state machine will be able to successfully marshal the entity through the defined workflow.








Come meet me at the 2017 LSNA!

[Jan Beran, geändert vor 6 Jahren.]

David, I see your point there. Would it reallly be such a problem for the Liferay processes though? I mean, the guys in the thread I linked made it work. Therefore, my original question was concerned with how to make the ext-plugin work.

Maybe, one simpler solution would be to use the OOB statuses in the WF definition, and simply "rename" them with a language.properties hook. Then I can change the CSS of the labels on the page that is displayed with javascript. I know it's a dirty hack, but it gets me where I need to be.

Thank you,

Jan

[David H Nebinger, geändert vor 6 Jahren.]

With 6.2 you should be able to implement what they did, you just have to get the change in the right path in the service portion of the ext plugin project.








Come meet me at the 2017 LSNA!