Bug 1012117 - Consistency of bundle mgr role post-upgrade
Consistency of bundle mgr role post-upgrade
Status: CLOSED CURRENTRELEASE
Product: JBoss Operations Network
Classification: JBoss
Component: Provisioning (Show other bugs)
JON 3.2
All All
unspecified Severity low
: ER04
: JON 3.2.0
Assigned To: Jay Shaughnessy
Mike Foley
:
Depends On:
Blocks: 1012435
  Show dependency treegraph
 
Reported: 2013-09-25 14:29 EDT by Viet Nguyen
Modified: 2014-01-02 15:37 EST (History)
4 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed:
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
screenshot (192.90 KB, image/png)
2013-09-25 14:29 EDT, Viet Nguyen
no flags Details

  None (edit)
Description Viet Nguyen 2013-09-25 14:29:45 EDT
Created attachment 803012 [details]
screenshot

Description of problem:

Manage Bundle role should have all rights checked after upgrade (3.1 -> 3.2)

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

How reproducible:


Steps to Reproduce:
1.  In JON 3.1 installation create a user with role Manage Bundle
2.  Upgrade to 3.2.  The user now has all individual Bundle permissions as well as Bundle groups (create, assign, etc).  

Actual results:
User can perform bundle group actions but Bundle Permissions table shows such rights unchecked

Expected results:
Bundle group rights all checked

Additional info:
Comment 1 Jay Shaughnessy 2013-10-09 11:26:38 EDT
This worked fine for me. Honestly, I can't see how it would be possible to have the permissions granted, as evidenced by the fact that "User can perform bundle group actions" and not have the permissions show up in the Roles view.

Please close or re-perform this test, or if I misinterpreted the problem please let me know.

(I did find a different upgrade problem while testing this, so it was a useful exercise!)
Comment 2 Viet Nguyen 2013-10-09 14:07:46 EDT
Clarification: nothing is 'broken' here.  After 3.1->3.2 upgrade Manage Bundle role in 3.1 can perform bundle group tasks in 3.2 as it should but the permission table shows those rights unchecked.
Comment 4 Jay Shaughnessy 2013-10-14 10:44:14 EDT
As mentioned above, I could not reproduce this.  The role showed the permissions correctly.  I'm setting this to modified for ER4 and suggest it be re-verified.
Comment 5 Simeon Pinder 2013-10-24 00:09:36 EDT
Moving to ON_QA for testing in the next build.
Comment 6 Viet Nguyen 2013-11-12 13:43:38 EST
Yes, bundle permission feature works as designed from an operational point of view, ie you can perform the bundle group-related tasks. This BZ is about how permissions are **displayed** after upgrading to 3.2.  Let's consider rhqadmin super user role. Post-upgrade it will have the new Manage Bundle group global permissions checked but none of the individual bundle group permissions are checked (Assign Bundles to Group, Unassign Bundles From Group, etc).  It's confusing to show a role with Manage Bundle Group global permission but that role does not have the right to Assign Bundles to Group.  

An analogy I can think of is showing linux root user with "manage files" permission but the right to 'delete files' box is unchecked.
Comment 7 Mike Foley 2013-11-12 13:52:08 EST
pm-222
Comment 8 John Mazzitelli 2013-11-13 09:03:51 EST
OK, now that I looked at the screenshot, I agree with Jay. This is all working fine and as expected.

Notice that the bundle permissiosn that are checked are the global permissions (look at the icons - the icon with the single box is the global permission - the multipe-boxes-icon is a group permission)

Those permissions that are not checked are GROUP permissions and are not global. Those should NOT get checked automatically just because you used to have the global permission. Only the new GLOBAL persmissions get checked if you used to have the old single global permission.

This is all working as expected.

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