Bug 1017062 - RBAC: Selector field disabled in Add JMS Queue dialog
RBAC: Selector field disabled in Add JMS Queue dialog
Status: CLOSED CURRENTRELEASE
Product: JBoss Enterprise Application Platform 6
Classification: JBoss
Component: Domain Management (Show other bugs)
6.2.0
Unspecified Unspecified
unspecified Severity high
: ER7
: EAP 6.2.0
Assigned To: Brian Stansberry
Ladislav Thon
Russell Dickenson
:
: 1019275 (view as bug list)
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2013-10-09 04:33 EDT by Jakub Cechacek
Modified: 2015-02-01 18:00 EST (History)
5 users (show)

See Also:
Fixed In Version:
Doc Type: Known Issue
Doc Text:
Cause: Consequence: Workaround (if any): Results:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2013-12-15 11:23:20 EST
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)


External Trackers
Tracker ID Priority Status Summary Last Updated
JBoss Issue Tracker HAL-262 Major Closed Selector field disabled in Add JMS Queue dialog 2015-05-19 01:17:00 EDT

  None (edit)
Description Jakub Cechacek 2013-10-09 04:33:39 EDT
Selector field in Add JMS Queue dialog is disabled
Comment 1 JBoss JIRA Server 2013-10-11 05:02:01 EDT
Heiko Braun <ike.braun@googlemail.com> updated the status of jira HAL-262 to Resolved
Comment 2 JBoss JIRA Server 2013-10-11 05:02:01 EDT
Heiko Braun <ike.braun@googlemail.com> made a comment on jira HAL-262

Not a UI issue
Comment 3 Heiko Braun 2013-10-11 05:03:30 EDT
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 09:34:45 EDT
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 07:56:18 EDT
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 11:53:04 EDT
Heiko Braun <ike.braun@googlemail.com> 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 10:27:42 EDT
*** Bug 1019275 has been marked as a duplicate of this bug. ***
Comment 8 Martin Svehla 2013-10-15 10:29:43 EDT
Same issue is also with durability checkbox in that dialog.
Comment 10 Jakub Cechacek 2013-11-06 03:05:01 EST
Verified 6.2.0.ER7
Comment 12 JBoss JIRA Server 2014-06-30 10:58:48 EDT
Heiko Braun <ike.braun@googlemail.com> 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.