This service will be undergoing maintenance at 00:00 UTC, 2016-08-01. It is expected to last about 1 hours
Bug 749415 - Fields need to be read only in drift definition editor
Fields need to be read only in drift definition editor
Status: CLOSED CURRENTRELEASE
Product: RHQ Project
Classification: Other
Component: drift (Show other bugs)
4.1
Unspecified Unspecified
medium Severity unspecified (vote)
: ---
: ---
Assigned To: John Sanda
Mike Foley
:
Depends On:
Blocks: 707225 rhq42 jon30-sprint8
  Show dependency treegraph
 
Reported: 2011-10-26 20:43 EDT by John Sanda
Modified: 2012-02-07 14:26 EST (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2012-02-07 14:26:33 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)

  None (edit)
Description John Sanda 2011-10-26 20:43:54 EDT
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-26 21:17:14 EDT
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-26 21:44:16 EDT
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 11:10:52 EDT
#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 11:12:51 EDT
#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 11:15:23 EDT
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 11:23:25 EDT
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 17:02:42 EDT
Added fix so that the pinned field is editable for scenario 2.

commit hash: d230e442f126d6d09d2b05188a4624310dcf990d
Comment 8 Mike Foley 2011-10-31 14:49:55 EDT
verified "pinned" is now editable.
Comment 9 Mike Foley 2011-10-31 15:57:41 EDT
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 16:01:33 EDT
step #4 is verified.
Comment 11 Mike Foley 2011-10-31 16:13:50 EDT
step #5 is verified
Comment 12 Mike Foley 2011-10-31 16:14:33 EDT
step #6 is verified
Comment 13 Mike Foley 2011-10-31 16:21:45 EDT
step #7 and #8 are verified
Comment 14 Charles Crouch 2011-11-01 07:32:11 EDT
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-01 20:37:28 EDT
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 05:18:03 EDT
So this is in rhq 4.2 and jon 3 ?
Comment 17 Mike Foley 2011-11-08 13:28:25 EST
verified jon3 branch
Comment 18 Mike Foley 2012-02-07 14:26:33 EST
changing status of VERIFIED BZs for JON 2.4.2 and JON 3.0 to CLOSED/CURRENTRELEASE

Note You need to log in before you can comment on or make changes to this bug.