Could you please install ovirt-engine-webadmin-portal-debuginfo ovirt-engine-userportal-debuginfo and share de-obfuscated exception as described in:

http://www.ovirt.org/develop/developer-guide/engine/engine-debug-obfuscated-ui/

I'm not sure if I missed something, but the deobfuscated info should already be included in the original request. I'll quote it to make it more legible:

---

Following the debug protocol, the culprit is inside the AD1ECDCCB07BD788E8B0C32BBE150B16 permutation. Checking the OUk entry:

OUk,org.ovirt.engine.ui.uicommonweb.IconUtils::extractIconIds(Ljava/util/Collection;ZZ)Ljava/util/List;,org.ovirt.engine.ui.uicommonweb.IconUtils,extractIconIds,org/ovirt/engine/ui/uicommonweb/IconUtils.java,43,28

Sorry Nicolas, I missed that part and saw only obfuscated part :-(

Tomas, could you please take a look?

Could you please check what does REST API returns for 
/ovirt-engine/api/vms
if you set Filter:true header and log in as the user for which it does not work?

Thank you!

Created attachment 1203793 [details]
Api request with filter=true

I'm providing the requested output as an attachment

I have a suspicion that this can happen in case the user has access to a VM pool but he does not have access to any VMs in this pool (e.g. all the VMs from this pool are already taken).
@Nicolas, could you please verify this is the case?

@Jakub: Looking at the logs, the null was the VM itself. I think in AbstractUserPortalListModel the GetVmDataByPoolId can return null and than the IconUtils.prefetchIcons will receive a list containing nulls.

@Nicolas: other question: what are all the roles the user has assigned? Especially in regards to the pools?

Indeed, the user has permissions over a pool that has no VMs (an empty pool). This is possibly because the machines in it had the "Delete protection" flag activated and after deleting the pool, the machines became stateless machines but the pool was not deleted.

Permissions for that user are:

VmCreator over the Data Center
DiskProfileUser over the Data Center
TemplateCreator over the Cluster
UserRole over the VM lubuntu-1404-desktop
UserRole over the DEMO VmPool (the empty one)

@Nicolas: could you please confirm that once you remove the UserRole from the DEMO pool the user portal works as expected?

While trying to simulate this issue, it seems that the whole delete protected does not work as expected on the pools. The correct fix should be that we will make sure we will not run into this situation.

Confirmed the exception disappears after removing permission on that pool

Great! Thank you for the fast responses!

The bug was not addressed in time for 4.1. Postponing to 4.2

Due to:
https://bugzilla.redhat.com/show_bug.cgi?id=1419520

one can hit this issue easily.

I think we need some simple null check to prevent this from happening.

When removing pool with Delete protecion the VMs stay and pool is removed.
But still userportal crashes when pool has no VMs.

tested in ovirt-engine-userportal-4.1.1-0.1.el7.noarch

2017-02-15 09:51:14,697+01 ERROR [org.ovirt.engine.ui.frontend.server.gwt.OvirtRemoteLoggingService] (default task-9) [] Permutation name: 361B776686563AF8BBE59716B1B0655D
2017-02-15 09:51:14,697+01 ERROR [org.ovirt.engine.ui.frontend.server.gwt.OvirtRemoteLoggingService] (default task-9) [] Uncaught exception: com.google.gwt.core.client.JavaScriptException: (TypeError)
 __gwt$exception: <skipped>: d is undefined
        at org.ovirt.engine.ui.uicommonweb.IconUtils.extractIconIds(IconUtils.java:43)
        at org.ovirt.engine.ui.uicommonweb.IconUtils.prefetchIcons(IconUtils.java:35)
        at org.ovirt.engine.ui.uicommonweb.models.userportal.AbstractUserPortalListModel$2.executed(AbstractUserPortalListModel.java:180)
        at org.ovirt.engine.ui.frontend.Frontend$3.$onSuccess(Frontend.java:328) [frontend.jar:]
        at org.ovirt.engine.ui.frontend.Frontend$3.onSuccess(Frontend.java:328) [frontend.jar:]
        at org.ovirt.engine.ui.frontend.communication.OperationProcessor$3.$onSuccess(OperationProcessor.java:176) [frontend.jar:]
        at org.ovirt.engine.ui.frontend.communication.OperationProcessor$3.onSuccess(OperationProcessor.java:176) [frontend.jar:]
        at org.ovirt.engine.ui.frontend.communication.GWTRPCCommunicationProvider$5$1.$onSuccess(GWTRPCCommunicationProvider.java:269) [frontend.jar:]
        at org.ovirt.engine.ui.frontend.communication.GWTRPCCommunicationProvider$5$1.onSuccess(GWTRPCCommunicationProvider.java:269) [frontend.jar:]
        at com.google.gwt.user.client.rpc.impl.RequestCallbackAdapter.onResponseReceived(RequestCallbackAdapter.java:198) [gwt-servlet.jar:]
        at com.google.gwt.http.client.Request.$fireOnResponseReceived(Request.java:237) [gwt-servlet.jar:]
        at com.google.gwt.http.client.RequestBuilder$1.onReadyStateChange(RequestBuilder.java:409) [gwt-servlet.jar:]
        at Unknown.SMd/c.onreadystatechange<(Unknown Source)
        at com.google.gwt.core.client.impl.Impl.apply(Impl.java:296) [gwt-servlet.jar:]
        at com.google.gwt.core.client.impl.Impl.entry0(Impl.java:335) [gwt-servlet.jar:]
        at Unknown._t/<(Unknown Source)
        at Unknown.anonymous(Unknown Source)

it's not going to be such interesting bug once the problem with empty pool is fixed, hence deferring

This issue is fixed on the new ovirt-web-ui which is deprecating the old user portal.