Note: This bug is displayed in read-only format because the product is no longer active in Red Hat Bugzilla.

Bug 976698

Summary: Duplicated workspaces share instances of Data providers
Product: [Retired] JBoss BPMS Platform 6 Reporter: Jan Hrcek <jhrcek>
Component: BAMAssignee: David Gutierrez <dgutierr>
Status: CLOSED WONTFIX QA Contact: Jan Hrcek <jhrcek>
Severity: low Docs Contact:
Priority: medium    
Version: 6.0.0CC: rzhang
Target Milestone: ER2   
Target Release: 6.0.0   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2013-08-28 06:07:04 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:

Description Jan Hrcek 2013-06-21 08:15:09 UTC
Description of problem:
When you duplicate some workspace, the data provider instances are shared between both original and duplicated workspace.

Version-Release number of selected component (if applicable):
Dashbuilder DR5 deployed on EAP 6.1

How reproducible:
always

Steps to Reproduce:
1. Login with root and navigate to workspace Showcase, page Data providers
2. Click "Delete data provider" for provider "Expense reports demo" -> alert "Cannot delete the data provider because it is being used by 5 KPI(s)" - accept alert
3. Click "Duplicate current workspace"
4. Repeat step 2 - only this time alert "Cannot delete the data provider because it is being used by 10 KPI(s)" is displayed. You will see the same alert when performing spet 2 in the duplicated workspace

Actual results:
The workspace duplication doesn't create unique DataProvider instances for the new workspace but instead reuses the instances used by the original workspace. This is also confirmed by inspecting the local application datasource.

Expected results:
I would expect the duplicated workspace to be completely independent of the original workspace (i.e. changes to one of them should not affect the other one) which is not the case if the Data Provider instances are shared.

One example where the problem manifests itself:
-User duplicates a workspace
-Now in the duplicated workspace he decides to delete data provider X
  -He goes to management (via General configuration) and deletes all Y KPI panels dependent on provider X (because of referential integrity contraints)
  -Then he goes to Data providers page and tries to delete the provider X
  -He gets error, that the provider is used by Y KPI panels (that reference our provider X from the original workspace)
  -If user only has access to duplicated workspace he will never be able to delete the provider Y until KPI's from original workspace are deleted

Comment 1 David Gutierrez 2013-07-01 09:03:39 UTC
Currently, there are some Dashbuilder artifacts that are "global" and thus shared among all the workspaces. Global asset types are: 

* Data providers (as you pointed out)
* Data connections to external data sources.
* Graphic resources: Skins, Page layouts and Workspace envelopes
* User roles

The Dashbuilder tool, as it's today, it's not intended to be used for implementing a pure SaaS solution. With SaaS I mean, an application installed on a single server which is able to manage separated client workspaces where each client has ownership of all the assets related with one or more dashboards. We can called this the "SaaS approach" which, unfortunately, is not supported currently. So the issue you're reporting it can't be fixed because it's not an expected feature.

On the contrary, the current approach assumes that the Dashbuilder application is being used by  only one company or organization. So an administrator user can handle any of the global assets defined. If someone wanted to set-up a SaaS like solution then it would install several Dashbuilder instances on different hosts.

To sum up, the "SaaS" requirement is not supported right now, but we can take it into consideration for further releases.