isrecursive not honoured for listAccounts, maybe others as well

[davidjumani]

ISSUE TYPE

• Bug Report

CLOUDSTACK VERSION

4.14 + (maybe even lower versions)

SUMMARY

isrecursive is not honoured when passed along with listall=true for listAccounts as a root admin
It is also not honoured when allow.user.view.all.domain.accounts is true

https://github.com/apache/cloudstack/blob/master/server/src/main/java/com/cloud/api/query/QueryManagerImpl.java#L2198-L2205

EXPECTED RESULTS

(qa) 🐱 > list accounts filter=name,domain domainid=e4874e10-5fdf-11ea-9a56-1e006800018c listall=true isrecursive=false 
{
  "account": [
    {
      "domain": "ROOT",
      "name": "admin"
    },
    {
      "domain": "ROOT",
      "name": "baremetal-system-account"
    },
    ................

ACTUAL RESULTS

(qa) 🐱 > list accounts filter=name,domain domainid=e4874e10-5fdf-11ea-9a56-1e006800018c listall=true isrecursive=false 
{
  "account": [
    {
      "domain": "ROOT",
      "name": "admin"
    },
    {
      "domain": "ROOT",
      "name": "baremetal-system-account"
    },
    {
      "domain": "small",            <- from a sub domain
      "name": "rick"
    },

[DaanHoogland]

so basically teh defined functionalities of listall and isrecursive overlap and listall prefails. iniutitively I'd say isrecursive should prefail, so FWIW I agree.

[ravening]

@davidjumani @DaanHoogland this issue exists for several api's if you call the api from the child domain

I have seen the same issue for listing service offering and disk offering as well. I have created a pr for it

Create the following domain relationship

ROOT -> test1 -> test11

Now login as test1 and create a service offering for test11 domain.
If you login as test11, you wont see it

[DaanHoogland]

@davidjumani @DaanHoogland this issue exists for several api's if you call the api from the child domain

I have seen the same issue for listing service offering and disk offering as well. I have created a pr for it

Create the following domain relationship

ROOT -> test1 -> test11

Now login as test1 and create a service offering for test11 domain.
If you login as test11, you wont see it

@ravening that sounds more like a problem with access than recursion, wouldn't you say so?

[ravening]

Not with recursion but how the code works

[DaanHoogland]

yes, well, domains have a concept of recursion but accounts do not. In the zone/pod/cluster/host there is another form of what could be called recursion. What you name above seems like a bug to me, but in general it is hard to define recursion consistently in cloudstack behaviour when it comes to these constructs.

Not with recursion but how the code works

Do you agree with how @davidjumani proposes to implement this?
And do you have other examples where it should behave the same?

I think what you mention about creating a service offering merits an issue ticket of its own.

[davidjumani]

I think that this is a deeper issue that could be across several elements. Need to look into whether this should be fixed. I personally think so and can raise a PR for the same but would like to get a wider feedback

[nvazquez]

@davidjumani reading the description of the parameters:

• listall: If set to false, list only resources belonging to the command's caller; if set to true - list resources that the caller is authorized to see. Default value is false
• isrecursive: defaults to false, but if true, lists all resources from the parent specified by the domainId till leaves.

Seems like these definitions might need a change, have you thought about a new behaviour?

[davidjumani]

@nvazquez Not just the definitions but the implementations as well

[nvazquez]

@davidjumani sure, my question was if you could explain what's your idea on the new implementation. Maybe easier to explain the new definitions of both parameter