Bug 1017786

The fix resolves the issue with the CLI, but I see that in the console the Deployer role still doesn't have permissions. The output of the access control metadata is correct though; the deployer role has write perms for all non-sensitive attributes and execute perms for all operations.

Ladislav Thon <lthon> made a comment on jira WFLY-2278

If the console still has a problem, do we want to file a HAL issue? Or is it enough to cc [~heiko.braun]?

Heiko Braun <ike.braun> made a comment on jira WFLY-2278

See https://issues.jboss.org/browse/HAL-273

Heiko Braun <ike.braun> made a comment on jira WFLY-2278

I don't see these issues in the console master. I would say it's safe to say it works.

Yes, but does this mean we need yet another console upgrade?

I'm targeting this for ER7. I didn't set it for ER6 because although the server-side change was in, I wasn't seeing the behavior I expected in the console. But it looks like it the console that will be integrated this week doesn't have these problems.

Verified with EAP 6.2.0.ER7.

Moving back to ON_QA as I didn't verify it in the web console. Preliminary check indicates that this ISN'T fixed in the console, but I might have done something wrong, so I'd like Jakub to recheck.

The console uses @AccessControl annotations to bind 1-n resources to presenters. Presenters are the "P" in the MVP architecture used in the console. Most presenters are addressable using an URL like http://localhost:9990/console/App.html#datasources. 

When the presenter is shown for the first time, the console reads the access control metadata of its configured resources to decide whether operations can be executed or attributes are readable/writable. 

The datasource presenter is configured using the following resources:
@AccessControl(resources = {
    "/{selected.profile}/subsystem=datasources/data-source=*",
    "/{selected.profile}/subsystem=datasources/xa-data-source=*"
})

The current implementation uses an "all-or-nothing" rule: If not all resources are writable, none will be writable. To cut a long story short. Making also the xa-data-source an application resource will give the deployer the permissions to edit both the data-source and the xa-data-source resource:

/core-service=management/access=authorization/constraint=application-classification/type=datasources/classification=data-source:write-attribute(name=configured-application, value=true)

/core-service=management/access=authorization/constraint=application-classification/type=datasources/classification=xa-data-source:write-attribute(name=configured-application, value=true)

This works for datasources, which is good news, but unfortunately it does not work for the other big use case for this feature, JMS queues and topics. That is, these 2 commands are insufficient to make Queues/Topics editable:

/core-service=management/access=authorization/constraint=application-classification/type=messaging/classification=jms-topic:write-attribute(name=configured-application,value=true)
/core-service=management/access=authorization/constraint=application-classification/type=messaging/classification=jms-queue:write-attribute(name=configured-application,value=true)

My guess as to the cause of this is that the relevant "Presenter" covers all sorts of other stuff, i.e. Connection Factories, Security Settings, Address Settings, Diverts, and these (correctly) cannot be configured to become "application resources."

I can confirm that the workaround with xa-data-source works. I filed bug 1027586 for tracking and I'm moving this to verified again. The main issue is indeed solved.