Do you see any additional issue besides the error?
Usually it is due to some change in the user-portal that caused running a query without the real need to. And, this query isn't a user query.

Sorry for late response didn't notice the needinfo.
UserPortal works properly, I didn't see any strange or wrong behaviour, just the error message in log.

So I wouldn't call it a regression.
We need to understand why it is there, but if it has no effect then it isn't any regression.

Ori - please try to reproduce, and check what query is being called there.
Probably some background admin-only query.

2015-09-24 15:07:52,040 TRACE [org.ovirt.engine.core.bll.GetConfigurationValueQuery] (ajp-/127.0.0.1:8702-12) [] START, GetConfigurationValueQuery(GetConfigurationValueParameters:{refresh='false', filtered='false', version='general', configurationValue='ApplicationMode'}), log id: 7289de9d
2015-09-24 15:07:52,040 TRACE [org.ovirt.engine.core.bll.GetConfigurationValueQuery] (ajp-/127.0.0.1:8702-12) [] FINISH, GetConfigurationValueQuery, log id: 7289de9d
2015-09-24 15:07:52,041 TRACE [org.ovirt.engine.core.bll.GetConfigurationValueQuery] (ajp-/127.0.0.1:8702-12) [] START, GetConfigurationValueQuery(GetConfigurationValueParameters:{refresh='false', filtered='false', version='general', configurationValue='ProductRPMVersion'}), log id: 5b47740d
2015-09-24 15:07:52,041 ERROR [org.ovirt.engine.core.bll.GetConfigurationValueQuery] (ajp-/127.0.0.1:8702-12) [] Query execution failed due to insufficient permissions.

I tried to reproduce the issue using the jdbc-aaa, however it was reproduced only once (seems that the cause of the failure is ValidateSessionQuery validation failure).

However, the rest of the attempts fails to produce the same error.
Is there any particular steps to reproduce this ? (i.e. first time user login)

Sucessfully reproduced on latest 3.6.(rhevm-backend-3.6.0-0.18.el6.noarch)

There are no specific steps.

Few new things noticed:

1) If user have admin permissions and login to UP the error is not shown. (so don't try ie with admin@internal)

2)
The error appears always after login at the same time. So I guess it's something invoked by scheduler. As you can see it's always 9:XX:32

2015-10-09 09:09:32,090 ERROR [org.ovirt.engine.core.bll.GetConfigurationValueQuery] (ajp-/127.0.0.1:8702-10) [] Query execution failed due to insufficient permissions.
2015-10-09 09:09:32,090 ERROR [org.ovirt.engine.api.restapi.resource.AbstractBackendResource] (ajp-/127.0.0.1:8702-10) [] Operation Failed: query execution failed due to insufficient permissions.
2015-10-09 09:10:32,090 ERROR [org.ovirt.engine.core.bll.GetConfigurationValueQuery] (ajp-/127.0.0.1:8702-1) [] Query execution failed due to insufficient permissions.
2015-10-09 09:10:32,091 ERROR [org.ovirt.engine.api.restapi.resource.AbstractBackendResource] (ajp-/127.0.0.1:8702-1) [] Operation Failed: query execution failed due to insufficient permissions.


2015-10-09 09:14:32,404 ERROR [org.ovirt.engine.core.bll.GetConfigurationValueQuery] (ajp-/127.0.0.1:8702-2) [] Query execution failed due to insufficient permissions.
2015-10-09 09:14:32,405 ERROR [org.ovirt.engine.api.restapi.resource.AbstractBackendResource] (ajp-/127.0.0.1:8702-2) [] Operation Failed: query execution failed due to insufficient permissions.


2015-10-09 09:16:32,415 ERROR [org.ovirt.engine.core.bll.GetConfigurationValueQuery] (ajp-/127.0.0.1:8702-7) [] Query execution failed due to insufficient permissions.
2015-10-09 09:16:32,415 ERROR [org.ovirt.engine.api.restapi.resource.AbstractBackendResource] (ajp-/127.0.0.1:8702-7) [] Operation Failed: query execution failed due to insufficient permissions.

Target release should be placed once a package build is known to fix a issue. Since this bug is not modified, the target version has been reset. Please use target milestone to plan a fix for a oVirt release.

In oVirt testing is done on single release by default. Therefore I'm removing the 4.0 flag. If you think this bug must be tested in 4.0 as well, please re-add the flag. Please note we might not have testing resources to handle the 4.0 clone.

I was able to reproduce the scenario on my env as well, however the exact sequence for 100% reproducible is the following:

1. Send a request via the restapi with a user which has no admin rights, without providing the 'filter=true' as part of the request's header.

User 'user1' has only 'User Role' permissions.

The following request will succeed:
curl -v -H "filter: true" -u "user1@internal:123456" http://localhost:8080/api/
...
< HTTP/1.1 200 OK
...
It uses the filter api, where the accessed resources are restricted according to the permissions the user has.

The following request will fail:
curl -v -u "user1@internal:123456" http://localhost:8080/api/
...
< HTTP/1.1 400 Bad Request
<fault>
    <reason>Operation Failed</reason>
    <detail>query execution failed due to insufficient permissions.</detail>
</fault>
...

This is a legit failure, since a non-admin user is attempting to access the admin api.


All of the logs above contains restapi specific errors, i.e.:
2015-07-08 15:10:21,667 ERROR [org.ovirt.engine.api.restapi.resource.AbstractBackendResource] (default task-8) [] Operation Failed: query execution failed due to insufficient permissions.

Therefore no UserPortal <--> Backend issue is raised.

Without a specific case of a failure to access 'User Portal' (any attempt to invoke a query from the user portal without passing the 'filter'), I'd suggest to close this bug as NOTABUG.

I can't reproduce now as well, the broken command is now sending the filter param corectly.

2015-11-02 08:43:06,744 TRACE [org.ovirt.engine.core.bll.GetConfigurationValueQuery] (ajp-/127.0.0.1:8702-9) [] START, GetConfigurationValueQuery(GetConfigurationValueParameters:{refresh='false', filtered='true', version='general', configurationValue='ProductRPMVersion'}), log id: 24eb41a3

But it could be some race. So I wouldn't close yet, I'll try to find the root cause.

Targeting to 4.0, in case it will still be relevant.

Closing as WORKSFORME.
If reproduced, please re-open.