this seems to be a really nice use case to customize the existing console. In my opinion achieving what you need is extremely easy with the new technology stack that we are using.
1) All the project tooling (for both Drools and jBPM) is based on a framework called Uberfire which internally uses Errai and GWT.
2) Your customizations sounds kinda simple to me, so creating a new Menu entry is just a couple of lines in a java class, we can create something generic something like and administration to that allows you to create on runtime new entries. That sounds as a good community contribution. Linking Tasks and Applications shouldn't be so difficult either, because we have listener that are used when tasks are created, that's where the logic of inserting a new row in the TASK_APPLICATION table should go.
My concern is more about what an Application means to you and why do you want to separate tasks by application. There are so many advantages of having an unified task list that I wonder if it's worth it. It will also be important for me to understand if business processes will be creating the tasks or not.
I'm pretty sure that you can achieve what you are looking for with the new tools, so feel free to ask questions if you need guidance on how to customize the project to meet your needs.
Thank you for your reply.
About "Application", let us say we have several modules and different users work on different modules. Users related to one module do not want to view tasks related to other modules.
And yes, the business process will be creating tasks. In Task properties we might need to pass application it belongs to, so that the link between task and application will be persisted to database.
Can you please provide more information on listener?
And to make any customization it seems I need to build form the sources rather than directly using the war files. Please confirm.
Also there are cases where one user can work on multiple applications, in this case user just wants to see the tasks group by application, rather than all applications tasks in one place.
At the same time, We may also need to customize dashboard to view application level reports.
1 of 1 people found this helpful
Your description about Applications sounds like Groups to me, if different processes create task for different groups, the users belonging to those groups will not see the tasks for all the other groups. Do you really need the Application concept?
In jBPM6 we have the TaskLifeCycleEventListener, you can provide your own implementation to get the application property when the task is being completed -> https://github.com/droolsjbpm/jbpm/blob/master/jbpm-human-task/jbpm-human-task-core/src/main/java/org/jbpm/services/task…
Look for implementations of that interface.
You can also look at this module as well -> https://github.com/droolsjbpm/jbpm/tree/master/jbpm-human-task/jbpm-human-task-audit
And yes, at this point if you want to modify the app you will need to clone the source code and compile it.
Ok, I do believe that we need to add the support for multiple task list under different "Categories" that means that an user can have different tasks lists based on "something" that can be defined by a filter criteria or something else like a property inside a task. Once again this sounds as a great community contribution
Exactly, this is what I am looking for.
About your comment 4, though we have "Groups" concept, there is possibility of having same user in multiple groups.
Yeah.. an user can belong to N groups, there is no problem with that.
Yeah, there is no problem with 1 User: N Groups, My comment 6 is to just enforce my requirement of having "Application".
Do we need to register the listener somewhere?
The listeners needs to be registered in the RuntimeManager listeners. So you can notify your app when a task was completed/created/suspended/etc.