[
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.
