Owned or accessible? I think by now this index endpoint morphed into the latter. In which case, should we include the public assets? Unless an account is passed, of course.

The docstring would need a rewrite, too.

Technically, it's also a breaking change in the API. We could maintain backwards compatibility if we add a new optional field that signals the caller wants to get all accessible accounts instead of the assets their own account owns. Or a new endpoint, but I don't favour that option, because it's still an asset index endpoint.

True, good point. I've included the parameter all_accessible (default=False).
This parameter signals if we want to get all the assets that the requesting user has read permissions or, by default, the ones that it owns.

What might nicely round this up would be to revise check_access to accept an as_account argument that defaults to the current user, in combination with putting back the permissions decorator.

So then we'd have the following four cases:

1. No account is passed, and all_accessible=false: caller wants to list their own assets
2. No account is passed, and all_accessible=true: caller wants to list all assets that they can access
3. An account is passed, and all_accessible=false: caller wants to list some other account's assets
4. an account is passed, and all_accessible=true: caller wants to list all assets that some other account can access. Caller requires read access on the passed account (checked using the decorator) and the passed account requires read access on the assets (to be checked using the revised check_access I suggested above).

One open point would be whether we should implicitly assume that, if the caller has access to account, it also has access to all accounts that account has access to. That is, we assume consultant permissions propagate.

Alternatively, we could call check_access on the assets for both the caller and the account (in case they are not the same). That is, we do not assume consultant permissions propagate.

Propagation has my preference. Whichever the case, we also might want to mention the choice of policy explicitly in the docs.

An unlikely case but possible is the user to have consultancy role but no read role. Thus, I think we can't really bring permission_required_for_context back. Perhaps, if len(accounts) == 0, we should raise Forbidden or Unauthorized.

Regarding the changes to the check_access, to my (superficial) understanding, they are already covered by the authorization policy:

1. No account is passed, and all_accessible=false: caller wants to list their own assets

Given that account is not passed, the marshmallow field will default to AccountIdField.load_current and check_access will make sure that the current user has read permissions for the account.

2. No account is passed, and all_accessible=true: caller wants to list all assets that they can access

In this scenario, the user could or couldn't have read access to his/her own account. Yet, it could have a consultant role and have access over the accounts that have the consultant_account_id set to the user's account.

3. An account is passed, and all_accessible=false: caller wants to list some other account's assets

check_access make sure that the requesting user has read permissions to its own account.

4. An account is passed, and all_accessible=true: caller wants to list all assets that some other account can access. Caller requires read access on the passed account (checked using the decorator) and the passed account requires read access on the assets (to be checked using the revised check_access I suggested above).

Here probably we should raise if the current user has no read permissions for its own account even if it has consultant role.

One open point would be whether we should implicitly assume that, if the caller has access to account, it also has access to all accounts that account has access to. That is, we assume consultant permissions propagate.

This is an interesting point, indeed. I think we should open a new issue for this and handle that on the Account __acl__ method.

Given that this touches auth policies I want to make sure we get @nhoening 's opinion, too.

Interesting solution!

• With the new structure, I guess we could deprecate the /public endpoint (as we can return public endpoints here), but if one * only* wants public assets, that would require loading a potentially long list and parsing the result. Or we add another parameter only_public.
• Consultancy is not propagating across multiple levels of accounts, and this is not the time or place to go there. We don't need it. Let's leave authorization (and check_access where it is right now)
• "An unlikely case but possible is the user to have consultancy role but no read role." I don't understand this. If you have that role, and your account is consultant of a client account, you can read client account data.
• I would also not do Case 4 ("An account is passed, and all_accessible=true: caller wants to list all assets that some other account can access."). Or is there a real use case? Why should we go to this trouble? We could say that both are not possible together and raise 422.
• Docstring can still be better: "List all assets that the user can access, on a given account (default: own) or all that the user has permission to read (excluding public)".

"An unlikely case but possible is the user to have consultancy role but no read role." I don't understand this. If you have that role, and your account is consultant of a client account, you can read client account data.

This is the case that a user has consultant roles but no doesn't have the read. This means that it can read their client's account but not his/her.

I would also not do Case 4 ("An account is passed, and all_accessible=true: caller wants to list all assets that some other account can access."). Or is there a real use case? Why should we go to this trouble? We could say that both are not possible together and raise 422.

I agree, currently we don't need to check what a user belonging to a different account can list. Also, If we were to implement this, it gets more complex because the user roles + account roles + consultancy relationship determine if a user can read an asset.