Bug 717550

Summary: Basic roles shall not be allowed to be deleted
Product: [Retired] CloudForms Cloud Engine Reporter: Shveta <ssachdev>
Component: aeolus-conductorAssignee: wes hayutin <whayutin>
Status: CLOSED ERRATA QA Contact: wes hayutin <whayutin>
Severity: medium Docs Contact:
Priority: unspecified    
Version: 1.0.0CC: akarol, asettle, athomas, cpelland, dajohnso, deltacloud-maint, dgao, dmacpher, hbrock, juwu, morazi, ssachdev
Target Milestone: betaKeywords: FutureFeature, Triaged
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: Doc Type: Enhancement
Doc Text:
Permission roles could be completely removed and users could enable an application into a state where no one had administrative rights. This bug fix removes the functionality so that permission roles can no longer be deleted.
Story Points: ---
Clone Of: Environment:
Last Closed: 2012-12-04 14:53:02 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:

Description Shveta 2011-06-29 08:12:33 UTC
Description of problem:


Version-Release number of selected component (if applicable):


How reproducible:


Steps to Reproduce:
1. As admin --> Control panel --> Roles
2. Select all roles and delete 
3. Once all roles are deleted , admin cannot perform any operation 
like creating user etc because of insufficient privileges
"You have insufficient privileges to perform action."
  
Actual results:


Expected results:


Additional info:

rpm -qa|grep aeolus
aeolus-configure-2.0.1-0.fc14.20110628141215gitb8aaf85.noarch
aeolus-conductor-daemons-0.3.0-0.fc14.20110628135944git2a88782.noarch
aeolus-all-0.3.0-0.fc14.20110628135944git2a88782.noarch
aeolus-conductor-doc-0.3.0-0.fc14.20110628135944git2a88782.noarch
rubygem-aeolus-cli-0.0.1-1.fc14.20110628165632git0dfe3ff.noarch
aeolus-conductor-0.3.0-0.fc14.20110628135944git2a88782.noarch

Comment 1 Scott Seago 2011-07-04 02:38:31 UTC
At the moment, the right solution here is unclear. From a back end point of view, there are no "magic roles" -- i.e. any role is allowed to be created/deleted, as it's possible that an admin will want to set up a different set of default permissions -- i.e. instead of one role that allows all admin privileges, they might want to split things up into separate roles, none of which can do _everything_.

It may be that certain roles should be identified as "non-modifiable" or "un-deletable", but would that flag also be one that couldn't be edited? Should we allow new roles but require that all "default" ones be left alone? That might make the eventual permissions UI confusing with the addition of new roles without being able to remove the defaults.

Comment 2 wes hayutin 2011-09-28 16:40:47 UTC
making sure all the bugs are at the right version for future queries

Comment 4 wes hayutin 2012-01-10 17:10:42 UTC
adding to ce-sprint-next

Comment 5 wes hayutin 2012-01-10 17:13:30 UTC
adding to ce-sprint-next

Comment 6 wes hayutin 2012-01-12 16:35:17 UTC
adding to ce-sprint

Comment 7 wes hayutin 2012-01-12 16:41:39 UTC
removing ce-sprint-next tracker

Comment 8 Angus Thomas 2012-01-13 16:10:16 UTC
The UI for 1.0 won't include support for editing roles, including deleting them. 

So, this is out of scope for 1.0

Comment 9 wes hayutin 2012-01-16 19:30:52 UTC
moving to 1.1

Comment 10 wes hayutin 2012-02-22 23:46:39 UTC
moving version to 1.0.0 .  version = found in version

Comment 11 Dave Johnson 2012-08-01 22:22:51 UTC
roles can no longer be deleted

Comment 14 Dave Johnson 2012-09-17 21:25:44 UTC
Roles can no longer be deleted...  good 2 go in CFCE v1.1 2012-09-14.5 puddle

Comment 16 errata-xmlrpc 2012-12-04 14:53:02 UTC
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

http://rhn.redhat.com/errata/RHEA-2012-1516.html