Bug 892642 - Disk permission don't disappear after disk is deleted(is shown as 'null(Disk)').
Disk permission don't disappear after disk is deleted(is shown as 'null(Disk)').
Status: CLOSED ERRATA
Product: Red Hat Enterprise Virtualization Manager
Classification: Red Hat
Component: ovirt-engine-webadmin-portal (Show other bugs)
3.1.0
Unspecified Unspecified
medium Severity medium
: ---
: 3.3.0
Assigned To: Maor
Aharon Canan
storage
: Reopened
: 886855 (view as bug list)
Depends On: 982527
Blocks: 915537
  Show dependency treegraph
 
Reported: 2013-01-07 08:48 EST by Ondra Machacek
Modified: 2016-02-10 15:22 EST (History)
15 users (show)

See Also:
Fixed In Version: is12
Doc Type: Bug Fix
Doc Text:
Previously, certain disks and permissions would be left in the database after forced removal of a storage domain or storage pool, resulting in partial titles remaining visible in the Permissions tab of the details pane for the User tab. With this update, the forced removal procedure has been updated to include the deletion of all disks and permissions from the database.
Story Points: ---
Clone Of:
Environment:
Last Closed: 2014-01-21 12:12:30 EST
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: Storage
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---
amureini: Triaged+


Attachments (Terms of Use)
engine.log (15.28 KB, text/x-log)
2013-01-07 08:48 EST, Ondra Machacek
no flags Details


External Trackers
Tracker ID Priority Status Summary Last Updated
oVirt gerrit 11737 None None None Never
oVirt gerrit 18153 None None None Never

  None (edit)
Description Ondra Machacek 2013-01-07 08:48:36 EST
Created attachment 674037 [details]
engine.log

Description of problem:
When user has permissions on disk. And then the disk is deleted. Under User->permissions tab there is still permissions to disk, but is shown as a 'null(Disk)'.

Version-Release number of selected component (if applicable):
3.1.0-38.el6ev

How reproducible:
always

Steps to Reproduce:
1. Create disk.
2. Add user permissions on this disk.
3. Remove disk.
4. Check users permissions.
  
Actual results:
User have permissions 'null(Disk)'

Expected results:
User should not have any permissions.

Additional info:
Comment 1 Ayal Baron 2013-01-09 02:39:01 EST
Daniel, is this a duplicate of another bug? I seem to recall seeing this issue before.
Comment 2 Daniel Erez 2013-01-09 08:17:15 EST
(In reply to comment #1)
> Daniel, is this a duplicate of another bug? I seem to recall seeing this
> issue before.

Yes, it's a duplicate of Bug 886855
Comment 3 Daniel Erez 2013-01-09 08:18:12 EST

*** This bug has been marked as a duplicate of bug 886855 ***
Comment 4 Daniel Erez 2013-01-09 09:21:45 EST
patch sent:
http://gerrit.ovirt.org/#/c/10798/4
Change-Id: I71210a641e21c211fce106096742bd72cf37c150
Comment 5 Daniel Erez 2013-01-09 09:23:30 EST
*** Bug 886855 has been marked as a duplicate of this bug. ***
Comment 7 Ondra Machacek 2013-02-04 16:20:23 EST
When disk is removed, then no permissions are seen in user permissions.

But it is still possible to view disk permission when storage is destroyed, as was described in bug 886855, which was marked as duplicated of this bug. So moving back to assigned.
Comment 8 Allon Mureinik 2013-02-15 17:37:16 EST
Need PM's input for proper behaviour of SD destruction - probably not feasible for 3.2
Comment 10 Ayal Baron 2013-08-05 04:24:23 EDT
Should be resolved by bug 982527, need to retest after it is fixed
Comment 13 Aharon Canan 2013-09-09 09:22:31 EDT
verified using is12

verification steps
1. Create disk.
2. Add new user (I added AD user)
2. Add the user permissions on this disk.
3. Remove disk.
4. Check that user permissions on the relevant disk disappeared 
       on users tab - select the relevant user - 
       on permissions sub-tab - check no relevant disk permissions
Comment 14 Charlie 2013-11-27 19:17:47 EST
This bug is currently attached to errata RHEA-2013:15231. If this change is not to be documented in the text for this errata please either remove it from the errata, set the requires_doc_text flag to minus (-), or leave a "Doc Text" value of "--no tech note required" if you do not have permission to alter the flag.

Otherwise to aid in the development of relevant and accurate release documentation, please fill out the "Doc Text" field above with these four (4) pieces of information:

* Cause: What actions or circumstances cause this bug to present.
* Consequence: What happens when the bug presents.
* Fix: What was done to fix the bug.
* Result: What now happens when the actions or circumstances above occur. (NB: this is not the same as 'the bug doesn't present anymore')

Once filled out, please set the "Doc Type" field to the appropriate value for the type of change made and submit your edits to the bug.

For further details on the Cause, Consequence, Fix, Result format please refer to:

https://bugzilla.redhat.com/page.cgi?id=fields.html#cf_release_notes 

Thanks in advance.
Comment 15 Sergey Gotliv 2013-12-08 04:26:42 EST
Described in BZ#982527
Comment 17 errata-xmlrpc 2014-01-21 12:12:30 EST
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/RHSA-2014-0038.html

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