-----Original Message----- From: Chip Childers [mailto:[email protected]] Sent: Tuesday, April 09, 2013 10:18 PM To: [email protected] Cc: Alena Prokharchyk Subject: Re: [DISCUSS] - Deletion of Users within the Admin account
On Tue, Apr 09, 2013 at 04:31:41PM +0000, Pranav Saxena wrote: > HI, > > Do we allow deletion of users created by the admin within the admin account ? > Currently if we see the UI (4.1 /master) and create a User within the admin > account you won't be able to delete any user . Now when you create a user , > its account type is 1 , account is Admin and domain is ROOT . With this in > mind , how do you distinguish between the system generated Admin user and a > manual generated user . > > Also , the delete User API if invoked for the admin himself will delete the > admin account leading to a big problem , since the admin won't be able to > login to the UI as his credentials will be deleted from the db. So first of > all we should have a check at the API layer to disallow such an action . > > Next , If I need to put a check at the UI layer to hide/show delete options , > what would be the right conditions needed to be checked to distinguish > between the system generated user and admin generated manual users ? > > Thanks, > Pranav Is this discussion tied to CLOUDSTACK-1941? [Pranav] - yes , it is Is the current state of 4.1 and master a change in behaviour from 4.0.0? [Pranav] - I didn't check 4.0 but the behavior in 4.1 and master seem to be exactly the same . If it isn't a change, I'd like to propose that we set the fix version to 4.2.0 at a minimum. Pending the outcome of this discussion thread, perhaps it will be closed with "won't fix", or perhaps it gets fixed. [Pranav] - Since the bug was marked as Critical for 4.1 , we can fix it in both . It is definitely an API bug which needs to be fixed as admin account should not be allowed to be deleted . Moreover from the UI perspective , I need a condition to distinguish between the two types of users to showcase delete options on the UI accordingly. If it *is* a change, can we implement a fix that restores past behaviour as a first step? [Pranav] - I believe , it should be a "demanding" change if at all 4.0 is also having a similar behavior ( which I am not sure of right now) since conceptually and technically we should not be following the current behavior in any version . -chip
