User cannot set their own default project

[Adam Young]

Setting Default project will create an assignment if it does not exist. However, if the relationship does exist, the user is stuck with the project that they were origianlly assigned to. If this project gets deleted, they may have a valid project, but no default project, and all of the problems that come along with that.

If the user could set their own default project to a project that they already have a role in, the problem goes away.

[Dolph Mathews (dolph)]

This was introduced by the fix for bug 1237989 in havana and would be resolved by https://blueprints.launchpad.net/keystone/+spec/attribute-access-privilege-based-on-role

[Dolph Mathews (dolph)]

Unassigning due to inactivity.

[Ajaya Agrawal (ajayaa)]

I understand that this bug would go away if the blueprint is implemented. Is someone working on the blueprint or is it not high on priority right now?

[OpenStack Infra (hudson-openstack)]

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

[OpenStack Infra (hudson-openstack)]

Change abandoned by Samuel de Medeiros Queiroz (<email address hidden>) on branch: master
Review: https://review.openstack.org/137254
Reason: It is a gap in the capabilities of a user. If we go down that path, maybe we need to make a user to update everything about themselves, not just password. Also, we can't just change the policy in this case, especially since changing the default project in v2 has access implications.

[Steve Martinelli (stevemar)]

unassigning due to inactivity

[Steve Martinelli (stevemar)]

Is this still a bug? Do we really want the user to be able to specify their own default project?

Actually, I thought the user could update the default project as part of a patch request? -- ah, but updating the user may not be in their policy...

I agree with samuel that this opens a new can of worms given our current design.

[Steve Martinelli (stevemar)]

unassigning due to inactivity

[Steve Martinelli (stevemar)]

See previous comments