aggregation: how to allow it only for specific conditions/queries?

[niwaa]

As an example, I would like to allow a user to get THEIR total count of articles, but not to have access to the total count of all articles.

• Aggregation in hasura is currently an all or nothing permission.
• I don't think I can do a custom SQL for that, as hasura need the return of the function to be a SETOF table object.

Any pointers on how I could achieve this?

[aylabbs]

This is an interesting question and perhaps you can explain better..

Permissions can be row specific and you can easily limit which rows a user can see by using the row level condition. The aggregation query will respect this setting.

I am assuming that you want to have it both ways... Regular query all rows so user can read articles but aggregate only their own.

While there are ways this can be accomplished, I am curious as to the point... If the user can just query all the rows and call .length on them on their client, why bother with this restriction.

If you must, you can make a VIEW of the table (just like SELECT author_id FROM article for example), redefine the relationships manually if necessary to traverse to user_id, and set row permission on this view to be author_id _eq: X-Hasura-User-Id and use this view for the aggr queries...

[niwaa]

So it is mostly for security / confidentiality purposes, as an example a website might not want to exposure the global total number of sales but still allow a specific users to get statistics of the sales they made.

SALES table :   id / seller_id / ... 
Seller X total sales :  30 (expose for each seller)
All sales: 2200  (this count need to stay private).

I also though of using a View, grouping sales count by user, and then to set row permission on this view as you mentioned. It is working, I can query it by user, just not sure how it will scale however as the view will get recalculated for each query for all users? It should be fine for medium sized app however.

But i think it is still a valid long term concern, aggregation queries can expose more business data than one would like, and it could make sense to have finer controls over them.

[aylabbs]

I think you are missing my point.

Aggregation queries currently respect row level checks. If you only allow a user to view their own articles, they will only see aggregations of the ones they can query. This is the standard behavior.

I assumed that you wanted to give other users access to some article data (in a blog scenario it doesn't help much to write an article if no one can read it...) and only allow a user to aggregate their own articles. If this is your intent, understand that my point above is still valid. If you are exposing all articles to anyone, you are essentially allowing them access to count them. Therefore, your use case is an edge use case and I explained how you can hack it.

If you just want to know about limiting aggregation queries to row level security, like I said, that is the standard behavior already. In your sales table example, that is what would happen.

[niwaa]

thanks, yes I think I get your point now... if articles are to be public, there is a way to get their total count anyway.

I'm still a bit confused in this case on how a business would prevent someone to track their number of users:
So even when putting "Limit number of rows" to 1 in users,
you can still count them by incrementing the offset on a query and count it (as a hack). And you are still forced to expose "users" rows if you want to simply display their usernames on "reviews", as example.

query {
  users (offset: 1... 1000){
    id
  }
}

I understand this might be an edge case, or maybe I'm still missing something.