Bug 1100635

Created attachment 898605 [details]
server.log showing the exception

Just testing it i have seend that it does not happens only when duplicating portals.

When removing a property from a SQL data provider, all the KPIs that use those data provider will fail with same exception. 

After removing "ts.taskid" property, you can navigate to "jbpm dashboard" portal and click on the tab "Tasks duration". It will fail as well.

It seems that the property is not removed in the datadisplayers related to the kpi's affected. I will continue trying to find the better solution.

The problem was with KPI displayers that are already configured.

These displayers are configured based on some data provider properties, if you change the data provider definition and remove some property that it's used by any displayer, it fails when rendering.

The fix consists of:

- Before rendering a data displayer, it checks if the properties used in this displayer are still present in the data provider.

- If data displayer contains a property/ies not present in the data provider, it shows a message indicating that "The KPI must be reconfigured" and the chart/table is not displayed.

- Then you have to use the edit mode of the KPI panel in order to modify the displayer configuration and set it correctly.


The fix has been applied to:
- KPI portlet
  -  Check if all used properties by the displayer are present in current data provider.
  - If not, shown an error message in order to force user to reconfigure it, as the chart or table is not displayed

- Dashboard Filter Portlet
  - Check if all visible properties by the filter are present in current data provider.
  - Check if currently being filtered properties by the filter are present in current data provider

- HTML portlet
  - It already supports as well if the property does not exist (not present in data provider ) and shows a "property not found" message. No modification needed.
Note that some interface methods has changed by adding throw an exception clause, but it was a must in order to achieve the new behavior.


Commits
*******
Commit in master -> https://github.com/droolsjbpm/dashboard-builder/commit/bbb2b273ed1ec814957c5f644bb130d89ea5832a

Commit in 6.2.x -> https://github.com/droolsjbpm/dashboard-builder/commit/ae5f596528505a5a7d513b18904097f283aeb851

Ok, now it works correctly. Verified with BPM Suite 6.1.0 ER3.

Reopening this BZ as it does not always work correctly in case of KPI panels.
Put shortly, in some cases when property is removed from the DataProvider, the KPI reconfigures itself to use different property, but then it displays nonsense data.

See video which illustrates the issue: after property is removed from the provider, the KPI reconfigures itself to use different property - but then it might end up displaying nonsense data without user noticing.

In this case I have simple testing H2 database (attached). To use it 
1) add jdbc driver of H2 db on dashbuilder's classpath (e.g. add <module name="com.h2database.h2"/> as dependency to dashbuilder.war/WEB-IN/jboss-deployment-structure.xml)
2) In dashbuilder create external connection with URL:
URL=jdbc:h2:/path/to/DataProviderManagement
username=dbUser
password=dbPassword

This DB contains 1 table (PERSON) with 4 columns (id, name, birthday, salary)

3) Create a KPI panel with domain=name, range=salary (range aggregation function = Average)
4) I edit Data provider SQL query, removing name column and reload page. I would expect the KPI to be marked as broken, but instead there seems to be some logic, that automatically changes KPI's range to different property (id in my case). So the KPI is not marked as broken, but instead it displays different data (domain=id, range=salary).
------------
What do you think? Is this behavior correct? I find it suspicious. Although it might be useful in preventing error messages being displayed, it might lead to dashboard displaying nonsense data without user noticing it.

Created attachment 979882 [details]
Kpi reconfigures itself instead of showing error

Created attachment 979883 [details]
Testing H2 db, username=dbUser, password=dbPassword

Hi Jan,

I'm agree with you in that point, but it's quite impossible by the application to know how to reconfigure the displayer when a property has been removed. I don't know which of the other properties make sense for using it... so what you propose it's really difficult, I don't know how to achieve it. I have talked with David too and he says the same, there is no solution for that case.

I think that the only solution we can try, instead of auto-reconfiguring the displayer when a property has been removed, is to let the displayer "bad-configured" when a property that uses is removed. It's same as when you create a new one: It doesn't shows any information or chart, it just shows the combo selection for dataprovider and then let the user reconfigure it by itself.

What do you think?

Hello Roger,

I don't want you to implement any sophisticated logic, I understand that it's impossible to chose meaningful replacement for the property removed in general. 
I was just confused that there are 2 possible outcomes after removing the property:
(1) the KPI auto-configures itself and just uses different (random) property for domain/range instead of the one you removed
(2) the panel somehow detects the change, displays the error messages and forces user to reconfigure it (behavior implemented for this BZ).

What I'm asking is if it's possible to be consistent and do either (1) or (2) (not both) in all cases. I think it would be better to go for option (2).

Imagine this scenario: a poor IT guy is responsible for configuring bunch of KPIs for his boss. The data is constantly changing and he adds or removes a property here or there. If some KPIs behave as in (1) he might not notice that he has broken something and he'll be scolded. Whereas if it always shows error as in (2), he'll be able to notice it and fix the configuration right away.

Hello Jan!

Ahh ok! np! Sure, you are right. I understand :)

I will try to apply same behaviour for all kinds of KPI displayers, as probably tables have a different behavior than charts in this aspect... so let me review it!

THanks!

Hi Jan,

Let's try now.

Commits:

- master -> https://github.com/droolsjbpm/dashboard-builder/commit/55bcfc69e9bb8eb70105581a79fa88f82119956b

- 6.2.x -> https://github.com/droolsjbpm/dashboard-builder/commit/b5ba9e2f8882a34e86d25d02a293c52368c4dd94

Ok, now it behaves as expected: after data provider property is removed, all dependent KPIs require reconfiguration.
Verified with BPM Suite 6.1.0 ER6