Bug 1196105

Summary:	Superclasses and @Position on fields - duplicate position value not detected
Product:	[Retired] JBoss BRMS Platform 6	Reporter:	Zuzana Krejčová <zkrejcov>
Component:	Data Modeler	Assignee:	Walter Medvedeo <wmedvede>
Status:	CLOSED WONTFIX	QA Contact:	Zuzana Krejčová <zkrejcov>
Severity:	medium	Docs Contact:
Priority:	medium
Version:	6.1.0	CC:	etirelli, kverlaen, lpetrovi
Target Milestone:	---
Target Release:	---
Hardware:	Unspecified
OS:	Unspecified
Whiteboard:
Fixed In Version:		Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2015-12-09 09:22:31 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 Zuzana Krejčová 2015-02-25 10:20:45 UTC

Description of problem:
See description in bug 1173089 comment 0.
While the issue of defaults was fixed (by not adding the annotation automatically), the issue for duplicate position values persists.

Data Modeler needs to warn about duplicate position on validation.


Version-Release number of selected component (if applicable):
6.1 ER5


Steps to Reproduce:
1. Create a data object C1 with field f1, set Position to 0. Save.
2. Create a data object C2, set the superclass to C1, add field f2, set Position to 0. Save.
3. Validate both data objects.


Actual results:
Step 3 - no errors.


Expected results:
Step 3 - Error pop-up warning about duplicate position, validation fails.

Comment 1 Walter Medvedeo 2015-02-26 08:43:07 UTC

When the position calculation, etc., was reviewed, it was determined that in fact the drools engine didn't worked as it was initially specified, etc., and the position auto calculation/assignment was no longer needed.
In Fact to have an auto assigned position, etc., was something that confused users.

Aditionally, it was stated that the Position is rarely used, and in case it's used, it's something that advanced users use.

It's true that it's very welcome to have an alert preventing users from position collisions with parent class, etc., but it's something not easy to solve in a consistent manner. So given the low probability of this scenario to happen in real business application, it was decided to not implement this control for this version.

Comment 2 Walter Medvedeo 2015-10-14 13:28:21 UTC

The above commentaries apply for this versión, the control was not implemented since we don't have a consistent manner to do it and we also had higher priority features to implement.

Comment 3 Walter Medvedeo 2015-12-09 09:22:31 UTC

The suggested check won't be implemented, so I close this BZ as part of the cleaning before moving to JIRA.