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
Works well on the 3.5 branch. Moving fix target to 3.6.
Shahar, on which branch you're testing this?
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?
on branch master and its work on REST not in the UI
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/
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.
(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')?
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.
since this BZ is marked as 'urgent', I am changing the Target Release to '3.5.1'.
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
(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.
Works OK with ovirt-engine-3.6.0-0.0.master.20150412172301.git55ba764.el7.centos.noarch
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.