Bug 831152 - Repositories Delete Selected Repository button leads to exception page when no permission is given
Summary: Repositories Delete Selected Repository button leads to exception page when n...
Keywords:
Status: CLOSED CURRENTRELEASE
Alias: None
Product: RHQ Project
Classification: Other
Component: Content
Version: 4.5
Hardware: All
OS: All
high
high
Target Milestone: ---
: RHQ 4.5.0
Assignee: RHQ Project Maintainer
QA Contact: Mike Foley
URL:
Whiteboard:
Depends On:
Blocks: 833114
TreeView+ depends on / blocked
 
Reported: 2012-06-12 10:30 UTC by Armine Hovsepyan
Modified: 2015-09-03 00:01 UTC (History)
3 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
: 833114 (view as bug list)
Environment:
Last Closed: 2013-08-31 10:11:59 UTC
Embargoed:


Attachments (Terms of Use)
delete repo (119.56 KB, image/png)
2012-06-12 10:30 UTC, Armine Hovsepyan
no flags Details

Description Armine Hovsepyan 2012-06-12 10:30:32 UTC
Created attachment 591161 [details]
delete repo

Description of problem:
For user with unchecked "Manage Repositories" permission- Delete repository shows red error (with some source data) on the top of the page

Version-Release number of selected component (if applicable):
JON - Version: 3.1.0.ER6

How reproducible:
always

Steps to Reproduce:
1.Log in with rhqadmin super user
2.Create role "testRole" with  Manage Repositories unchecked
3.Create "testUser" user with this role
4.Log in with "testUser"
5.Click Administration navigation tab
6.Click  Repositories sub navigation on the left hand side
7. Click on "Create New" and by filling name and description create new repo
8. Select created repository 
9. Click Delete Selected button
  
Actual results:
Red error with some source data [like "invocation: method=public void org.rhq.enterprise.server.content.ContentSourceManagerBean.purgeOrphanedPackageVersions(org.rhq.core.domain.auth.Subject),context-data={}" ] is visible on the top of the page

Expected results:
After step97. "?????" Either Delete button is not visible, or just no error is shown, or the error doesn't contain "source" data  ???????

Additional info:
please get attached screenshot

Comment 1 Jay Shaughnessy 2012-06-15 20:53:53 UTC
This is odd.  We let a user without MANAGE_REPOSITORIES create a repo.  I think the delete operation generating a permission exception is actually correct.  I'm not sure why we allow create to work, it seems that should fail as well although maybe I don't know all the semantics.

Perhaps the Administration->Repositories should be disabled for a user without MANAGE_REPOSITORIES permission.  But that is GUI issue, the create is potentially an SLSB level issue.

Comment 2 Jay Shaughnessy 2012-06-18 14:09:14 UTC
OK, looking at the code, the create seems OK.  We allow a user to create a private repository.  And, lacking MANAGE_REPOSITORIES, we ensure that it is set private even if the global option is requested.

So, the problem here is that the user can not then delete his own repo.  That is a real problem.  I'm taking this...

Comment 3 Jay Shaughnessy 2012-06-18 15:38:12 UTC
master commit 5a8b4196beed872022861c0d4110a652c0f5c013
A private repo should be able to be deleted by its owner, even if the owner
does not have MANAGE_REPOSITORIES permission.

Comment 4 Armine Hovsepyan 2012-07-11 11:38:36 UTC
Please look at the scenario below:

1. Create user with MANAGE_REPOSITORIES role
2. Create repo where the owner is either NONE or NOT_CURRENT_USER
3. Remote MANAGE_REPOSITORIES role from user's role
4. Enter the administration -> repositories 

Question: Should the repos be shown? Should it be possible to remove those repos?

Comment 5 Armine Hovsepyan 2012-07-11 13:51:38 UTC
verified.

Scenario is the following: user can ONLY remove the repositories OWNED by him and will see error message on the top of the page if he tried to remove a global repositories, even if those are created by him, when he doesn't have MANAGE_REPOSITORIES permission.

Comment 6 Heiko W. Rupp 2013-08-31 10:11:59 UTC
Bulk close of old bugs in VERIFIED state.


Note You need to log in before you can comment on or make changes to this bug.