Bug 749415

Summary:	Fields need to be read only in drift definition editor
Product:	[Other] RHQ Project	Reporter:	John Sanda <jsanda>
Component:	drift	Assignee:	John Sanda <jsanda>
Status:	CLOSED CURRENTRELEASE	QA Contact:	Mike Foley <mfoley>
Severity:	unspecified	Docs Contact:
Priority:	medium
Version:	4.1	CC:	hrupp
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:	2012-02-07 19:26:33 UTC	Type:	---
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:
Bug Depends On:
Bug Blocks:	707225, 734807, 745494

Description John Sanda 2011-10-27 00:43:54 UTC

Description of problem:
The drift definition editor is used in different contexts. Depending on the context, some fields should be read-only or they shouldn't be displayed at all. I will enumerate below the various scenarios in which the drift definition editor is used and point out which fields should be read-only not rendered at all.

Possible fields:
* Name
* Description
* Enabled
* Attached
* Pinned
* Drift Handling Mode
* Interval
* Base Directory
* Includes
* Excludes

1. Create a drift definition from an unpinned template
Here the editor is being used to create a new drift definition. All fields should be rendered and editable.

2. Edit a definition that is created from an unpinned template
All fields should be rendered. The following fields should be read-only - name, base directory, includes, and excludes.

3. Create a definition from a pinned template
All fields should be rendered. The following fields should be read-only - attached, pinned, base directory, includes, and excludes.

4. Edit a definition created from a pinned template
All fields should be rendered. The following fields should be read-only - name, attached, pinned, base directory, includes, excludes.

5. Create an unpinned template (from an existing unpinned template)
The attached and pinned fields should not be rendered. All other fields that are rendered should be editable.

6. Edit an unpinned template
The attached and pinned fields should not be rendered. The name, base directory, includes, and excludes fields should be read-only.

7. Create a pinned template (from an existing pinned template or from a snapshot)
The attached and pinned fields should not be rendered. The base directory, includes, and excludes fields should be read-only.

8. Edit a pinned template
The attached and pinned fields should not be rendered. The name, base directory, includes, and excludes fields should be read-only.

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

How reproducible:

Steps to Reproduce:
1.
2.
3.

Actual results:

Expected results:

Additional info:

Comment 1 John Sanda 2011-10-27 01:17:14 UTC

For scenarios two and four the pinned field should be rendered and read-only. In scenario two it should be set to false and in scenario four it should be set to true.

Comment 2 John Sanda 2011-10-27 01:44:16 UTC

I have committed changes that I think cover all of the above scenarios; however, before this bug is verified, It may be good for QE, Jay, and myself to go over them to make sure that the scenarios I listed are correct.

commit hash: 3af3311a04c8959b65660abf2bd6e26cf39991c1

Comment 3 Mike Foley 2011-10-28 15:10:52 UTC

#1 is verified.  1. Create a drift definition from an unpinned template
Here the editor is being used to create a new drift definition. All fields
should be rendered and editable.

Comment 4 Mike Foley 2011-10-28 15:12:51 UTC

#2 is verified.  2. Edit a definition that is created from an unpinned template
All fields should be rendered. The following fields should be read-only - name,
base directory, includes, and excludes.

Comment 5 Mike Foley 2011-10-28 15:15:23 UTC

ah ... on step #2 ... i now notice that "pinned" is also read-only.  that is unexpected.  fail to verify/agree with expectations.  jsanda, can you clarify if this is expected or a bug?

Comment 6 John Sanda 2011-10-28 15:23:25 UTC

That is definitely a bug. With the pinned field being set to read-only there is no way to unpin the definition. And we do intend to support resource-level unpinning. That is, if you pin a definition to a snapshot, you should be able to unpin the definition. Now if a definition is pinned to a template, we do not want to allow for the definition to be unpinned.

Comment 7 John Sanda 2011-10-28 21:02:42 UTC

Added fix so that the pinned field is editable for scenario 2.

commit hash: d230e442f126d6d09d2b05188a4624310dcf990d

Comment 8 Mike Foley 2011-10-31 18:49:55 UTC

verified "pinned" is now editable.

Comment 9 Mike Foley 2011-10-31 19:57:41 UTC

step #3 is verified.  i worked thru this with jsanda.  

you start with a snapshot ... and create a new drift template.  i verified the drift template is created.  on the template ... the includes, excludes, and base directory are read-only.  the pinned field is on the list view ... but not on the detail view.

on the drift configuration, the configuration remains un-pinned....which is confusing ... but correct.  discussed with jsanda

Comment 10 Mike Foley 2011-10-31 20:01:33 UTC

step #4 is verified.

Comment 11 Mike Foley 2011-10-31 20:13:50 UTC

step #5 is verified

Comment 12 Mike Foley 2011-10-31 20:14:33 UTC

step #6 is verified

Comment 13 Mike Foley 2011-10-31 20:21:45 UTC

step #7 and #8 are verified

Comment 14 Charles Crouch 2011-11-01 11:32:11 UTC

Reopening so we make sure we don't miss this in the cut over to the jon3x 
release branch. This fix is in master, but not in the release branch currently

Comment 15 John Sanda 2011-11-02 00:37:28 UTC

The commits for this bug are in the release_jon3.x branch. Here are the commit hashes,

3af3311a04c8959b65660abf2bd6e26cf39991c1
670c2a76b570312eedc71e6d1bffaaadae39e2d1

Moving back to ON_QA.

Comment 16 Heiko W. Rupp 2011-11-04 09:18:03 UTC

So this is in rhq 4.2 and jon 3 ?

Comment 17 Mike Foley 2011-11-08 18:28:25 UTC

verified jon3 branch

Comment 18 Mike Foley 2012-02-07 19:26:33 UTC

changing status of VERIFIED BZs for JON 2.4.2 and JON 3.0 to CLOSED/CURRENTRELEASE