Motty, would you be kind to review this?

(In reply to Germano Veit Michel from comment #0)
> Description of problem:
> 
> I have a few doubts on how this is supposed to work, but AFAIK this is a bug.
> 
> Users cannot use non Public vNIC Profiles even if permission explicitly
> added.
> 
> 1. Create internal user and set password:
> 2. Create Network (GermanoNet) with two profiles:
>    * GNet (Public)
>    * GNetNotPublic (Not Public)
> 3. Assign VmCreator role to user (germano)
> 4. User tries to create VM, only sees GNet(GNet) Network/vNIC profile. This
> is expected, all good.
> 
> Currently the permissions view look like this:
> 
>      object_name      |   owner_name   | object_type  |    role_name    
> ----------------------+----------------+--------------+-----------------
>  GermanoNet           | admin  (admin) | Network      | NetworkAdmin
>  GNetNotPublic        | admin  (admin) | vNIC Profile | NetworkAdmin
>  GNet                 | admin  (admin) | vNIC Profile | NetworkAdmin
>  GNet                 | Everyone       | vNIC Profile | VnicProfileUser
> 
> 5. Go to the networks tab and add the following permission on the GermanoNet
> network:
>    User: germano
>    Role: VnicProfileUser
> 
> This is the result:
> 
> 
>      object_name      |        owner_name        | object_type  |   
> role_name    
> ----------------------+--------------------------+--------------+------------
> -----
>  GermanoNet           | admin  (admin)           | Network      |
> NetworkAdmin
>  GermanoNet           | Germano Michel (germano) | Network      |
> VnicProfileUser
>  GNetNotPublic        | admin  (admin)           | vNIC Profile |
> NetworkAdmin
>  GNet                 | admin  (admin)           | vNIC Profile |
> NetworkAdmin
>  GNet                 | Everyone                 | vNIC Profile |
> VnicProfileUser
> 
> Shouldn't it also create a object_type_id 27 (vNIC profile) permission for
> the Germano user? It's just creating id 20 (network) on step 5.

No, it shouldn't. It creates the exact permission you've asked for:
VnicProfileUser role for user 'germano' on network 'GermanoNet'.

The reason it shouldn't create additional permission entry for each of the network's vnic profiles is due to the multi-level-administration.
If another profile will be added for that network, user 'germano' will have the 'VnicProfileUser' for it due to the hierarchical structure of the permissions model. 

In addition, all of the permissions of vnic profiles are listed in the following view: user_vnic_profile_permissions_view_base which should contain also permissions the user has on the vnic profile's network.

> 
> What happens now is that if I login with user germano, I cannot see the
> GNetNotPublic profile when creating a VM. I only see GNet(GNet).
> 
> Now I do step 5 again and use the NetworkAdmin role. This is added
> 
>      object_name      |        owner_name        | object_type  |   
> role_name    
> ----------------------+--------------------------+--------------+------------
> -----
>  GermanoNet           | admin  (admin)           | Network      |
> NetworkAdmin
>  GermanoNet           | Germano Michel (germano) | Network      |
> NetworkAdmin
>  GermanoNet           | Germano Michel (germano) | Network      |
> VnicProfileUser
>  GNetNotPublic        | admin  (admin)           | vNIC Profile |
> NetworkAdmin
>  GNet                 | admin  (admin)           | vNIC Profile |
> NetworkAdmin
>  GNet                 | Everyone                 | vNIC Profile |
> VnicProfileUser
> 
> So still no change in the vNIC profiles (id 27). User can't use or see them
> in the User Portal.
> 

The following entry:
     object_name      |        owner_name        | object_type  |    role_name    
----------------------+--------------------------+--------------+----------------
 GermanoNet           | Germano Michel (germano) | Network      | VnicProfileUser

means that user 'germano' should be able to view and use all of the profiles of network 'GermanoNet'.

This is also part of the design [1]:
"User (as opposed to an administrator), will be limited to the networks and VNIC profiles he can see. ===== VNIC Profiles ===== NOTE: the permissions used below besides the direct one, and the VM/Template one, must allow the user to view the child objects

The user has direct user permissions on the VNIC profile
The user has user permissions on the VNIC profile's network"

[1] http://www.ovirt.org/develop/release-management/features/sla/vnic-profiles/

> Version-Release number of selected component (if applicable):
> ovirt-engine-4.1.4
> 
> How reproducible:
> 100%
> 
> Steps to Reproduce:
> As above

Dan, it seems like a regression.

(In reply to Moti Asayag from comment #2)
> 
> Dan, it seems like a regression.

Pavel, is this tested? Can you tell which version has introduced this regression?

(In reply to Moti Asayag from comment #2)
> The reason it shouldn't create additional permission entry for each of the
> network's vnic profiles is due to the multi-level-administration.
> If another profile will be added for that network, user 'germano' will have
> the 'VnicProfileUser' for it due to the hierarchical structure of the
> permissions model. 
> 
> In addition, all of the permissions of vnic profiles are listed in the
> following view: user_vnic_profile_permissions_view_base which should contain
> also permissions the user has on the vnic profile's network.

Understood. Thanks.

Is there any other data I can provide that would help clearing why the profiles are not shown even if the user has permission to the network?

(In reply to Dan Kenigsberg from comment #3)
> (In reply to Moti Asayag from comment #2)
> > 
> > Dan, it seems like a regression.
> 
> Pavel, is this tested? Can you tell which version has introduced this
> regression?

This particular test case is not part of our automation at the moment but we'll be working to include this in the near future. 
I'm afraid that in order to find out on which version this regression was introduced, we would have to try and reproduce this on previous versions.

Verified on:
ovirt-engine-4.1.7.3-0.0.master.20171001124835.git8d9e821.el7.centos.noarch

User is able to see both public and non public vnic profiles at VM creation.

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.

https://access.redhat.com/errata/RHEA-2018:1488

BZ<2>Jira Resync

sync2jira

sync2jira

sync2jira

sync2jira