Bug 1164744

Summary:	Cannot add action to roles
Product:	[Retired] oVirt	Reporter:	Shahar Havivi <shavivi>
Component:	ovirt-engine-core	Assignee:	Alexander Wels <awels>
Status:	CLOSED CURRENTRELEASE	QA Contact:	Ondra Machacek <omachace>
Severity:	urgent	Docs Contact:
Priority:	urgent
Version:	unspecified	CC:	awels, bugs, ecohen, gklein, lsurette, oourfali, rbalakri, shavivi, yeylon
Target Milestone:	---
Target Release:	3.6.0
Hardware:	Unspecified
OS:	Unspecified
Whiteboard:	infra
Fixed In Version:	ovirt-engine-3.6.0-0.0.master.20150412172306.git55ba764	Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2015-11-04 11:30:18 UTC	Type:	Bug
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	Infra	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:

Description Shahar Havivi 2014-11-17 09:58:54 UTC

Description of problem:
When adding a new role with actions only the role added, no actions is set,
This is true to edit role (tested in REST as well with no success).

How reproducible (UI):
1. Press "configure" at the right corner at the top toolbar
2. Press "new" button
3. set the name for the role and select few actions (such as Template->Basic Operations->Edit Properties)
4. edit the same role that you added - the actions where never saved

Comment 1 Oved Ourfali 2014-11-18 08:37:37 UTC

Works well on the 3.5 branch.
Moving fix target to 3.6.

Comment 2 Yair Zaslavsky 2014-11-18 10:14:07 UTC

Shahar, on which branch you're testing this?

Comment 3 Oved Ourfali 2014-11-18 10:16:26 UTC

Seems like it works well on 3.5, and not on master.
In addition, I debugged the issue and the engine gets only the LOGIN action group.
The selection in the UI is being ignored totally.
Also, it works well on the REST API, as opposed to what is selected in the description.

Alexander - can you assist us with that?

Comment 4 Shahar Havivi 2014-11-18 11:08:12 UTC

on branch master and its work on REST not in the UI

Comment 5 Alexander Wels 2014-11-18 14:16:51 UTC

Yes this is most likely due to my giant re-factor patch [1], I will take a look at it now.


[1] http://gerrit.ovirt.org/#/c/34193/

Comment 6 Alexander Wels 2014-11-19 14:36:49 UTC

Okay it turns out the patch has nothing to do with the problem. For some reason the detach handler is fired right before the tree is shown, this removes the handlers from the tree that handle the clicks. This causes the selection to not be reflected in the backing model. So in essence it doesn't register the fact that certain actions are assigned to the role which results in the observed behaviour.

I am trying to figure out why the detach handler is fired right before the tree becomes visible.

Comment 7 Einav Cohen 2014-11-19 14:47:19 UTC

(In reply to Alexander Wels from comment #6)
> Okay it turns out the patch has nothing to do with the problem. For some
> reason the detach handler is fired right before the tree is shown, this
> removes the handlers from the tree that handle the clicks. This causes the
> selection to not be reflected in the backing model. So in essence it doesn't
> register the fact that certain actions are assigned to the role which
> results in the observed behaviour.
> 
> I am trying to figure out why the detach handler is fired right before the
> tree becomes visible.

Thanks, Alexander - maybe worth finding out what is the patch that caused this using 'git blame' or similar - once you find out what it the exact piece of code responsible for the current behavior (this should be a fairly-recent patch, given that it doesn't reproduce in 3.5 - only in 'master')?

Comment 8 Alexander Wels 2014-11-19 16:26:20 UTC

I haven't figured out what happened to make this break, but I have found a good solution to the problem, so I am posting a patch.

Comment 9 Einav Cohen 2014-11-19 16:43:01 UTC

since this BZ is marked as 'urgent', I am changing the Target Release to '3.5.1'.

Comment 10 Alexander Wels 2014-11-19 17:51:48 UTC

Since this doesn't appear to happen in 3.5, not sure why we are going to back port it. The patch should have no issues being back ported, but it is definitely a master only issue.

@Einav
Are you sure you want to get this back ported to 3.5

Comment 11 Einav Cohen 2014-11-19 17:57:02 UTC

(In reply to Alexander Wels from comment #10)
> Since this doesn't appear to happen in 3.5, not sure why we are going to
> back port it. The patch should have no issues being back ported, but it is
> definitely a master only issue.
> 
> @Einav
> Are you sure you want to get this back ported to 3.5

my mistake - thanks for correcting me, Alexander. 
Re-targeting for 3.6.

Comment 12 Ondra Machacek 2015-05-12 08:38:25 UTC

Works OK with ovirt-engine-3.6.0-0.0.master.20150412172301.git55ba764.el7.centos.noarch

Comment 13 Sandro Bonazzola 2015-11-04 11:30:18 UTC

oVirt 3.6.0 has been released on November 4th, 2015 and should fix this issue.
If problems still persist, please open a new BZ and reference this one.