delta/openstack/python-openstackclient.git/openstackclient/identity/v3/role.py, branch 1.7.0

Remove backticks from help in role commands

2015-09-19T04:40:21+00:00

the docs and code had inconsistencies with how it
references other arguments, lets just remove the
backticks from around them.

Change-Id: I43d17b07364e45387c6b9d86c2aca26eeea8ed93

Use a common decorator to log 'take_action' activation

2015-09-01T23:49:54+00:00

Instead of duplicating the same log statement throughout
the code, the same logic can be provided by a shared decorator
that abstracts away the logging capability and unifies it behind
a common function instead.

Change-Id: Icc63bced7347c8bbf0299a4c5821425a10892a79

Use correct domain to find project

2015-08-11T06:49:20+00:00

When adding a role to a group and project OSC is mistakenly using the
group_domain to find the project which will fail if the group_domain !=
project_domain.

Change-Id: I4c1bec9b3b183c755be121b91f40e026d707192b
Closes-Bug: #1483520

Fixes inherited role assignments CRUD calls

2015-08-06T15:05:57+00:00

The paremeter to Keystone Client was passed as
'inherited', when it should be
'os_inherit_extension_inherited'.

Closes-Bug: #1482254

Change-Id: I1cb46add532223ef0b9620763b1047cc80e19ec0

Add support to inherited project role grant calls

2015-06-22T14:05:01+00:00

Once inherited project role grant calls are
implemented on python-keystoneclient,
python-openstackclient also should support such
calls.
This patch add such support as well as its
related tests.

Co-Authored-By: Raildo Mascena 

Change-Id: Id72670be8640e5c6e2490a6ef849e9ec3493b1a9
Implements: blueprint hierarchical-multitenancy

Refactor option handling for user|group|project domain scoping

2015-06-17T16:38:40+00:00

put the common options in identity.common, this way the help is
consistent

Change-Id: I5b09cfb56fa0f8d16feb95150f216fccbe9f2b22

Enable specifying domain for group and role commands

2015-06-08T14:05:10+00:00

Many of the commands for the group and role resources were lacking an
option to specify the specific domain groups, projects or users belong
to. This commit fixes that.

Change-Id: I461d2bcfd01ad2dea970de38ec7ad6f4a631ceb1
Closes-bug: #1446546

Enable specifing domains in "role add"

2015-05-12T08:48:01+00:00

If users, projects or groups are provided by name, there is a
possibility of the existence other users/projects/groups with the same
name in other domain.  Even though this is not a problem if the actual
ID is given instead of a name; this is mostly a usability enhancement.

So, three options were added, one for specifying the domain where the
user belongs, another one to specify the project's domain, and finally
one to specify the group's domain.

Change-Id: Iab04b0e04fa75ea5aa3723b8ea42a45f58a6cdb2
Closes-Bug: #1421328

Role operations should not require list object permission

2015-04-17T17:14:57+00:00

When using Keystone's policy.v3cloudsample.json policy file, a project admin is
supposed to be able to manage role assignments.  Unfortunately, a project admin
isn't allowed to perform these operations using python-openstackclient, as we
attempt to perform list operations for any of the object types specified (users,
groups, projects). This is done in an attempt to lookup the id of the object by
name, but we perform this list operation even when the user specifies everything
by id. This causes 403 errors.

This patch still attempts to look up the object id by name, but we catch the 403
and assume that the user specified an id if the list operation is not allowed.
This is similar to what we do with the --domain option for other commands.

Closes-bug: #1445528
Change-Id: Id95a8520e935c1092d5a22ecd8ea01f572334ac8

Fine tune some of the helps commands

2015-01-13T05:58:57+00:00

try and add some consistency with the show and delete commands.

replace 'show x' with 'display x'
change 'delete a y' with just 'delete y'

Change-Id: I47dfa8ee23ac5c41b355796415eb515155832f65