Note: This is a beta release of Red Hat Bugzilla 5.0. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Also email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback here.
Bug 1065461 - readOnly configuration is editable via CLI
Summary: readOnly configuration is editable via CLI
Alias: None
Product: JBoss Operations Network
Classification: JBoss
Component: CLI
Version: JON 3.2
Hardware: Unspecified
OS: Unspecified
Target Milestone: DR01
: JON 3.3.0
Assignee: Jay Shaughnessy
QA Contact: Filip Brychta
Depends On:
TreeView+ depends on / blocked
Reported: 2014-02-14 17:28 UTC by Armine Hovsepyan
Modified: 2015-09-03 00:02 UTC (History)
7 users (show)

Doc Type: Bug Fix
Doc Text:
Clone Of:
Last Closed: 2014-12-11 14:02:30 UTC
Type: Bug

Attachments (Terms of Use)
readOnly_config_update (deleted)
2014-02-14 17:28 UTC, Armine Hovsepyan
no flags Details

System ID Priority Status Summary Last Updated
Red Hat Bugzilla 1090005 None None None Never
Red Hat Bugzilla 1092975 None None None Never
Red Hat Bugzilla 1099447 None None None Never

Internal Links: 1090005 1092975 1099447

Description Armine Hovsepyan 2014-02-14 17:28:57 UTC
Created attachment 863347 [details]

Description of problem:
readOnly configuration is editable via CLI

Version-Release number of selected component (if applicable):
build: 2dd5c24 (as well as jon 3.2)

How reproducible:

Steps to Reproduce:
1. Get configuration of a resource with readOnly config properties (e.g. EAP -> transactions -> log-store or RHQ Storage -> Keyspaces -> (rhq, system_outh, etc.)
2. Run the following CLI command:
var config = ConfigurationManager.getLiveResourceConfiguration(${log-store-id},true); 
conf.setSimpleValue("type","def") // which by default is "default"

Actual results:
the following log is visible:
	configuration: Configuration[id=28247, notes=Resource config for Log Store (Standalone) Resource w/ id 15018]
	createdTime: 1392398351130
	duration: 49
	id: 12272
	modifiedTime: 1392398351130
	resource: Resource[id=15018, uuid=d8f1386b-081d-4c37-bcea-77d37ccce2d6, type={JBossAS7}Log Store (Standalone), key=subsystem=transactions,log-store=log-store, name=log-store]
	status: In Progress
	subjectName: rhqadmin

Expected results:
Message telling resource config is read_only

Additional info:
In GUI the value from "def" is changed back to "default" , while the history shows it has been changed. Config is not editable on GUI.
screen-shot attached

Comment 1 Jay Shaughnessy 2014-04-04 21:10:04 UTC
This is working as expected. Read-only is treated like other field validation and is applied only in the GUI ConfigurationEditor.

Users with appropriate permissions are allowed to update Configurations directly via the API.

master commit f882515fa88b93a553f3c78e6250c4916ae1a585
Author: Jay Shaughnessy <>
Date:   Fri Apr 4 17:07:57 2014 -0400

 Update some jdoc to reflect that this is the expected behavior when calling
 from the CLI. read-only and other validation is applied only via the
 GUI's ConfigurationEditor.

Comment 2 Jay Shaughnessy 2014-04-04 21:11:12 UTC
Armine, given the above, can I move this to modified or closed?  or is this really an RFE?

Comment 3 Armine Hovsepyan 2014-04-07 09:06:47 UTC
@Alan, could you please answer to Jay's question in comment #2. 

I expect rhqadmin has the same permissions in GUI and CLI, unless there's an RFE telling "rhqadmin has permissions to update read-only configs via CLI only".

Comment 4 Alan Santos 2014-04-07 13:57:07 UTC
I agree with Armine that this is a bug.  

If something is read only it shouldn't allow the resource to be updated and/or it shouldn't incorrectly report that the configuration has been updated when it hasn't.

Comment 5 Jay Shaughnessy 2014-04-08 15:35:38 UTC
OK, so it's been classified as a bug by QE and PM. Regardless, before I set out to make this change I want to caution people that I think it could have unwanted or unexpected side-effects.  I think it's possible that our code, or possibly custom client code, could have assumed it can make any updates to any Configuration. Enforcing readOnly=true for programmatic changes to configuration may make sense, I'm not sure, but although it may catch problems it may also have the potential to cause problems.

Waiting for the green light from Heiko...

Comment 6 Heiko W. Rupp 2014-04-08 15:52:29 UTC
I think enforcing it makes sense as a savvy user could otherwise just work around the restrictions in the UI and use the CLI here. And even if the plugin would reject it and the change would not be made on the target resource, it is confusing as shown above, where a change shows in history for something that should be read-only.

Comment 7 Jay Shaughnessy 2014-04-08 15:59:48 UTC
OK, proceeding..

(11:57:00 AM) jshaughn: pilhuhn: I'm assuming the whole config update would fail, right?
(11:58:11 AM) pilhuhn: I think that may be best, as it is atomic. Otherwise the user does not really know which properties were accepted and which not.

Comment 8 Jay Shaughnessy 2014-04-09 21:18:52 UTC
master commit 8eff7c11cae1d137b78467101f866c7d3bfca241
Author: Jay Shaughnessy <>
Date:   Wed Apr 9 17:08:45 2014 -0400

    Add a new signature to ConfigurationUtility.validateConfiguration that
    takes both a newConfiguration and currentConfiguration and ensure the new
    config does not alter any non-empty readOnly property value.

    Enhance ConfigurationManagerBean.update*Configuration() to perform the new
    validation.  Added some tests and updated the Remote method jdoc.

Comment 9 Simeon Pinder 2014-07-31 15:51:42 UTC
Moving to ON_QA as available to test with brew build of DR01:

Comment 10 Filip Brychta 2014-08-04 14:15:20 UTC
Verified on
Version :	
Build Number :	

ConfigurationManager.updateResourceConfiguration(13254,conf); [Warning] Bad parameter(s) given: Invalid newResourceConfiguration, configuration not updated: [ReadOnly property 'type' has a value [test] different than the current value [default]. It is not allowed to change.]

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