Description of problem: same problem as https://bugzilla.redhat.com/show_bug.cgi?id=854296 for other permissions. Version-Release number of selected component (if applicable): How reproducible: Steps to Reproduce: 1. 2. 3. Actual results: Expected results: Additional info: IMHO header 'Filter: {value: true|false, required: false}' should be also for? -- TemplateOwner permissions -- /api/templates/{template:id}|rel=delete /api/templates/{template:id}|rel=update /api/templates|rel=add -- DiskOperator permissions -- /api/templates/*|rel=* -- vmpool operations(PowerUserRole) -- /api/vmpools/*|rel=*
Ondrej , please explain which operations you are trying to perform and the list of permissions your users has .
It looks like API related issue , please change bug component if needed .
I think it is same issues as bz 854296, because everything works for me with via REST API. Some things I tryied: 1) Add user with "TemplateOwner" role on DC. 2) Try to run code below. code(version of ovirtsdk is 3.2.0.1): API = ovirtsdk.api.API( url='https://url:443/api', insecure=True, username='newUser', password='password', filter=True) vm = API.vms.get(name='vmName') API.templates.add(params.Template(name='templateName', vm=vm)) # Fails # same for template.nics.add(params.NIC()) # same for API.templates.get(templateName).delete() Getting an error: query execution failed due to insufficient permissions. This error is getting also via REST API if i use curl and don't use "Filter: true" header. After some playing around i think 'filter' header is missing in all permission which are the same for Admin roles and user roles. That are all permissions which has these roles: TemplateOwner, DiskCreator, TemplateCreator, VmCreator, DiskOperator, UserVmManager, PowerUserRole, UserRole.
Michael - are there operations that we shouldn't pass the filter header to? If the answer is no, shouldn't we somehow use the filter header definition (Filter: {value: true|false, required: false}) only in one place, making all the actions inherit it?
(In reply to comment #4) > Michael - are there operations that we shouldn't pass the filter header to? good question, asaf? > If the answer is no, shouldn't we somehow use the filter header definition > (Filter: {value: true|false, required: false}) only in one place, making all > the actions inherit it? it's doable, worth case, api will ignore it
(In reply to comment #5) > (In reply to comment #4) > > Michael - are there operations that we shouldn't pass the filter header to? > > good question, asaf? > > > If the answer is no, shouldn't we somehow use the filter header definition > > (Filter: {value: true|false, required: false}) only in one place, making all > > the actions inherit it? > > it's doable, worth case, api will ignore it ok, before we decide on making global filter=x, is there a use-case that admin user would like to run method X as filtered=true and method Y as filtered=false?
(In reply to comment #6) > (In reply to comment #5) > > (In reply to comment #4) > > > Michael - are there operations that we shouldn't pass the filter header to? > > > > good question, asaf? > > > > > If the answer is no, shouldn't we somehow use the filter header definition > > > (Filter: {value: true|false, required: false}) only in one place, making all > > > the actions inherit it? > > > > it's doable, worth case, api will ignore it > > ok, before we decide on making global filter=x, is there a use-case > that admin user would like to run method X as filtered=true and method > Y as filtered=false? mention functionality can be achieved via: api.set_filter(true|false) between method invocations rhevm-sdk: make /filter header global rather than method driven
we can wait for that use case to happen. but, iirc, there is planned work on handling multiple connections to different ovirt engines. that would mean diffrenet credentials to different engines. it would also mean for each connection different filter mode. so i'd argue filter mode can be a connection level property. and sdk should allow working with two connections to same engine, one filtered, and one not. actually, in a connection broker (user portal) implementation, i'd expect the code to keep a connection per user to same engine (and use filtred mode for all).