Heiko Braun <ike.braun> updated the status of jira HAL-262 to Resolved

Heiko Braun <ike.braun> made a comment on jira HAL-262

Not a UI issue

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" => {}
            }
        }
    }]
}

Maybe the same thing as the datasource issue Jakub reported? That is, a side effect related to the "application" constraint.

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.

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.

*** Bug 1019275 has been marked as a duplicate of this bug. ***

Same issue is also with durability checkbox in that dialog.

Verified 6.2.0.ER7

Heiko Braun <ike.braun> updated the status of jira HAL-262 to Closed