Mailing-List: contact derby-dev-help@db.apache.org; run by ezmlm
Precedence: bulk
Reply-To: <derby-dev@db.apache.org>
Message-ID: <1380350524.1240936770581.JavaMail.jira@brutus>
Date: Tue, 28 Apr 2009 09:39:30 -0700 (PDT)
From: "Dag H. Wanvik (JIRA)" <jira@apache.org>
To: derby-dev@db.apache.org
Subject: [jira] Commented: (DERBY-4161) SQL Roles - Clarify documentation
 regarding the SET ROLE
In-Reply-To: <1927564078.1239802277334.JavaMail.jira@brutus>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit


    [ https://issues.apache.org/jira/browse/DERBY-4161?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12703709#action_12703709 ] 

Dag H. Wanvik commented on DERBY-4161:
--------------------------------------

Thanks, Kim! Sorry for the late comment on this issue.
Looks good, just one clarification:

> SET ROLE taskLeaderA;

> If the database owner granted the taskLeaderA role to a user, that user would have all the privileges associated with the > taskLeaderA, updater, and reader roles.

The first part of the above statement is a bit misleading, in that if the role has *not* been granted to the user,
the SET ROLE statement would fail. Perhaps say,

Presuming the database owner granted the taskLeaderA role to a user, that user be allowed to set the role as shown and would have all the privileges granted to the taskLeaderA, updater, and reader roles.


> SQL Roles - Clarify documentation regarding the SET ROLE
> --------------------------------------------------------
>
>                 Key: DERBY-4161
>                 URL: https://issues.apache.org/jira/browse/DERBY-4161
>             Project: Derby
>          Issue Type: Improvement
>          Components: Documentation
>    Affects Versions: 10.5.1.1
>            Reporter: Tiago R. Espinha
>            Assignee: Kim Haase
>         Attachments: cdevcsecureroles.html, DERBY-4161.diff
>
>
> After discussing this issue on the mailing list, it has been agreed that the documentation regarding the usage of SQL roles needs to be clarified.
> Namely, it should be clearer that a session does not have a role set by default and that as such, a SET ROLE must be issued to enable a specific role.
> Further along the path, we may want to have the ability of setting a default role but for now and for the release of 10.5 this is the shortest and best course to follow.
> Kim had already suggested an addition to the documentation on the list; maybe she'd like to take on this issue?

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.