Bug 1017062 - RBAC: Selector field disabled in Add JMS Queue dialog
Summary: RBAC: Selector field disabled in Add JMS Queue dialog
Keywords:
Status: CLOSED CURRENTRELEASE
Alias: None
Product: JBoss Enterprise Application Platform 6
Classification: JBoss
Component: Domain Management
Version: 6.2.0
Hardware: Unspecified
OS: Unspecified
unspecified
high
Target Milestone: ER7
: EAP 6.2.0
Assignee: Brian Stansberry
QA Contact: Ladislav Thon
Russell Dickenson
URL:
Whiteboard:
: 1019275 (view as bug list)
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2013-10-09 08:33 UTC by Jakub Cechacek
Modified: 2015-02-01 23:00 UTC (History)
5 users (show)

Fixed In Version:
Doc Type: Known Issue
Doc Text:
Cause: Consequence: Workaround (if any): Results:
Clone Of:
Environment:
Last Closed: 2013-12-15 16:23:20 UTC
Type: Bug


Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Red Hat Issue Tracker HAL-262 0 Major Closed Selector field disabled in Add JMS Queue dialog 2015-05-19 05:17:00 UTC

Description Jakub Cechacek 2013-10-09 08:33:39 UTC
Selector field in Add JMS Queue dialog is disabled

Comment 1 JBoss JIRA Server 2013-10-11 09:02:01 UTC
Heiko Braun <ike.braun> updated the status of jira HAL-262 to Resolved

Comment 2 JBoss JIRA Server 2013-10-11 09:02:01 UTC
Heiko Braun <ike.braun> made a comment on jira HAL-262

Not a UI issue

Comment 3 Heiko Braun 2013-10-11 09:03:30 UTC
It's a problem with the server side permissions:


[domain@localhost:9999 /] /profile=full/subsystem=messaging/hornetq-server=default/jms-queue=*:read-resource-description(access-control=trim-descriptions){roles=SuperUser}
{
    "outcome" => "success",
    "result" => [{
        "address" => [
            ("profile" => "full"),
            ("subsystem" => "messaging"),
            ("hornetq-server" => "default"),
            ("jms-queue" => "*")
        ],
        "outcome" => "success",
        "result" => {
            "description" => undefined,
            "access-constraints" => {"application" => {"jms-queue" => {"type" => "messaging"}}},
            "attributes" => undefined,
            "operations" => undefined,
            "children" => {},
            "access-control" => {
                "default" => {
                    "read" => true,
                    "write" => true,
                    "attributes" => {
                        "selector" => {
                            "read" => true,
                            "write" => false
                        },
                        "entries" => {
                            "read" => true,
                            "write" => false
                        },
                        "durable" => {
                            "read" => true,
                            "write" => false
                        }
                    }
                },
                "exceptions" => {}
            }
        }
    }]
}

Comment 4 Brian Stansberry 2013-10-11 13:34:45 UTC
Maybe the same thing as the datasource issue Jakub reported? That is, a side effect related to the "application" constraint.

Comment 5 Brian Stansberry 2013-10-14 11:56:18 UTC
I'm speculating, but my guess is this is because the fields are not writable after the add operation.

That makes me think the issue is the decision to return "false" for access-control  => write on a read-only attribute. We did that because saying "true" was confusing if the attribute couldn't be modified by anyone. That reasoning makes sense from the point of view of whether the attribute can be modified, but not from the add point of view. 

I think we're better off just returning write => true in these situations and just accepting that the other metadata that describes whether an attribute is read-write is what describes the general ability to write. The folks who are going to be asking for the access-control metadata are sophisticated clients and I think it's not too much for them to understand this subtlety.

Comment 6 JBoss JIRA Server 2013-10-14 15:53:04 UTC
Heiko Braun <ike.braun> made a comment on jira HAL-262

+1 one on this:

I think we're better off just returning write => true in these situations and just accepting that the other metadata that describes whether an attribute is read-write is what describes the general ability to write. The folks who are going to be asking for the access-control metadata are sophisticated clients and I think it's not too much for them to understand this subtlety.

Comment 7 Martin Svehla 2013-10-15 14:27:42 UTC
*** Bug 1019275 has been marked as a duplicate of this bug. ***

Comment 8 Martin Svehla 2013-10-15 14:29:43 UTC
Same issue is also with durability checkbox in that dialog.

Comment 10 Jakub Cechacek 2013-11-06 08:05:01 UTC
Verified 6.2.0.ER7

Comment 12 JBoss JIRA Server 2014-06-30 14:58:48 UTC
Heiko Braun <ike.braun> updated the status of jira HAL-262 to Closed


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