new extension to customize workflow activities query
As of now every component (dashboard, workflow activity window) that needs to get the list of all activities for a user has a copy of the query, and does not use a centralized one.
Will be added a new osgi extension to be able to customize it, and such new method will be centrilzed to have a single point where the query is generated.
Hi , regarding price (but was just an example) we used IProductPricing and factory to add the feature of being able to use a rule to get price and discounts.
Regarding using a sysconfig or customizing the default clause for the specific pont of this issue i understand your point but i dont like the fact of having a plugin wich is standard for our installations to depend on sysconfig or other customization for its basic functionality (while i can agree with you if this was a customization for a single installation).
I guess this may be closed as refused, thanks for interesting pointers and opinions.
Another probably easier possibility would be to add a SysConfig tenant key like WORKFLOW_ACTIVITY_ADDITIONAL_FILTER, would be very easy to add that and it can support different filters based on tenant.
SQL strings can be written in java to be readable.
I usually use http://www.dpriver.com/pp/sqlformat.htm to help me with that task, for example this one:
I committed that change mostly to improve readability of the SQL:
For future also, java 13 will bring multi-line strings support.
About customizing "to determine price for products" -> we implemented that in - Pluggable product pricing
Now, for the specific of this ticket. Reading the code it seems interesting - the actual WHERE is already configurable in the Document Status "Workflow Activities" PA_DocumentStatus_ID=200004
One idea could be to change the WWFActivity.getWhereActivities to read that table instead of the hardcoded filter - that way the form will be in sync with the numbers shown there.
We moved the sql to an extenal file (not for trivial queries) because having endless string made it very difficult to maintain the code and extract the query. This way we can keep it well formatted and readable,, easy to extract to test against the db. An additional benefit we got is that we can directly reference the queries used by the code via link to versioning system, so the analysys document (we keep a wiki for it) always refer to the version used by the program.
An inexperienced developer/analyst can cause unexpected damage in many ways, included groovy script. They are dangerous but also a very useful feature (And most of the dangers does not come per-se from being able to create valdators in groovy but much by the poor write/debug experience).
Last, but very not least, in our local reality (italy) every customer has slightly peculiar behaviour so we had to implement some workaround with queries from db (to determine price for products, for example) to avoid having to do a custom implementation every single time. Being able to fine tune some queries for a specific customer may be quite useful.
But maybe thats a specific issues other countries does not have.
We added a feature to link workflow to request status, this creates activities like a normal worklow but they are not meant to be managed by ui. So we needed a way to exclude that activities from the counts of total activites and from the list of tasks to manage (maybe this list of changes is partial, i cant check the code right now).
This use case is an example of “managed from plugin” ovveride of base sql.
Hi , agree with you, readability and maintability of code suffers.
Duplicate sql statements are usually solved moving the query to the proper model class in a "getRecords" method.
And if we find the need to allow externally modifying one specific query we need to evaluate how to make it robust (i.e. ensuring that new columns are discovered dinamically).
So, I would propose, let's start from the beginning.
: why do you need to customize the list of activities? Which columns are required in those plugins that are not in the core query/queries?
Which is the use case? Does the code manage changes to the SQL without requiring changes on visualization code?