Editing User fails when the user already has a Primary Project

Ah... My bad, I forgot to update my devstack settings with a better HORIZON_CONFIG variable.

The error is somewhat nicer in that case. There's both a success message and "Error: Unable to update (<django.utils.functional.__proxy__ object at 0x7f6a818d7790>,) for the user". I'll open a new bug for the translation issue, sorry for the noise!

Reopening this -- although the error is caught and displayed, we probably shouldn't force the user to select a Primary Project if setting it (multiple times) is going to cause an error.

This is only a problem when using Keystone v2.0.

Looks like keystone's API is behaving as expected.

@dolph: I think something more is going on here. With v2.0 I get a 409 every time if the user is already a member of the project, even if they have never had a default project before.

User.update_user_project() seems very naive:

https://github.com/openstack/keystone/blob/71c6a4b88279ddf9047595fb4c1ffbce4062621d/keystone/identity/controllers.py#L247

Shouldn't this be checking whether the user is already on the project?

Hmm, looks like you're probably right-- definitely worth investigating

There is a different behavior for v2.0 and v3 on Horizon side:
with v2.0: horizon calls keystone's update_user_project method which both adds the user to a project and updates the user settings
with v3: horizon updates the user only -> after changing user's prject, we have to add the user on prject's user management page explicitly

Temporary workaround for the Keystone's issue pointed out by @kspear could be 2 separate calls: update_user (which updates user's tenantId attr), then add this user to primary project (if he is not added yet).

On Horizon side we should add a call which adds user to project after update for v3:
https://github.com/openstack/horizon/blob/master/openstack_dashboard/api/keystone.py#L325

That's an intentional difference. The goal is to allow users to revise their own default project as a preference, while on v2 it was treated as an administrative operation and resulted in a change in authorization.

Fix proposed to branch: master
Review: https://review.openstack.org/31559

@Kieran: I was able to reproduce a 409 with v2.0 (see tests in https://review.openstack.org/31559 ) when attempting to update the user to the pre-existing default project. However, the fact that the test was running in it's previous state was covering the "even if they have never had a default project before." Is there some other contributing factor to reproducing the issue as you described?

@Kieran: Refactored my tests after patchset 1, so the above is in reference to the original test_user_create_update_delete in https://review.openstack.org/#/c/31559/1/tests/test_keystoneclient.py

@Dolph: Thanks, your fix looks good. I removed the tenantId from the DB manually when testing, but I was thinking of a case like:

Create user with no tenantId specified
Add user to tenant x
Set user's default tenant to tenant x

The root cause is the same though, so your existing test covers it.

On Horizon side do we want to add the user to the selected primary project as a member (if she is not member yet) as described in comment #7?

Fix proposed to branch: stable/grizzly
Review: https://review.openstack.org/31707

Reviewed: https://review.openstack.org/31559
Committed: http://github.com/openstack/keystone/commit/2ff3ddd356d599677bfc2a1ad08009b2226357eb
Submitter: Jenkins
Branch: master

commit 2ff3ddd356d599677bfc2a1ad08009b2226357eb
Author: Dolph Mathews <email address hidden>
Date: Mon Jun 3 15:30:10 2013 -0500

    Ignore conflict on v2 auto role assignment (bug 1161963)

    Change-Id: I10581a39325b4fcdb997ad704c3ee0de494b32e0

@Jan: I think the v2 way of doing things is somewhat dangerous, since you can accidentally select the wrong project as default, and it's not obvious that they get added to the project when you do so. Would be interested to hear other's thoughts, but personally I'd rather we only list the current projects for the edited user in the dropdown.

Fix proposed to branch: master
Review: https://review.openstack.org/32454

Reviewed: https://review.openstack.org/32454
Committed: http://github.com/openstack/horizon/commit/c123e2abb48b8e72b279258d272d661a5146ebb8
Submitter: Jenkins
Branch: master

commit c123e2abb48b8e72b279258d272d661a5146ebb8
Author: Jan Provaznik <email address hidden>
Date: Mon Jun 10 17:46:08 2013 +0200

    List only projects accessible by user

    When setting user's primary project, display only projects accessible
    by user being updated.

    Fixes bug 1161963

    Change-Id: Ib83f3a1ee83b8d0441267254582824a3fe07b4e3

Reviewed: https://review.openstack.org/31707
Committed: http://github.com/openstack/keystone/commit/e44685113a7e6cd7a77d0647c85eab2689938435
Submitter: Jenkins
Branch: stable/grizzly

commit e44685113a7e6cd7a77d0647c85eab2689938435
Author: Dolph Mathews <email address hidden>
Date: Mon Jun 3 15:30:10 2013 -0500

    Ignore conflict on v2 auto role assignment (bug 1161963)

    Change-Id: I10581a39325b4fcdb997ad704c3ee0de494b32e0