Deploy preview for hasura-docs ready!

Built with commit 233ab64

https://deploy-preview-4110--hasura-docs.netlify.com

Review app for commit 233ab64 deployed to Heroku: https://hge-ci-pull-4110.herokuapp.com
Docker image for server: hasura/graphql-engine:pull4110-233ab645

Thanks for the RFCs! I've read through them and the features proposed seem to go a long way to meet our needs.

As I understand it, we'll be able to disable subscriptions altogether, enable querying for some of the entities just via relations and enable/disable the use of certain fields in filter conditions. Thats great!

One scenario that seems to be not covered is multi-field filtering - you need to enable filtering on all the fields from the condition and that means users can filter only on the second or further column in the index. Eg to use index on order_items_extended_attributes with columns (tenant, order_item_id, name) we would have to enable column name. And in that case someone could make a query filtering just by name which wouldn't use the index.

This would also make our permissioning setup so much cleaner (and likely more performant). As of now for our more nested data models, e.g. organization -> project -> things in project, we need to basically repeat all of the org and project permission checks on the tables for things inside of the project. This will be a fantastic change 👍. Any idea on rough timeline post RFC acceptance? Months, quarters?

We currently resort to schema stitching to achieve this; would love to see this feature

Really need this. Any prospects on the implementation of this feature? Thanks!

Could the rfc add the possibility to disable the where argument #5751

Is anyone looking into the implementation?

Hi, this would be a killer feature for us.

However why limit that to query and subscriptions ? I would add the ability to manage the same permissions for mutations too.

Any plans to implement blocking root level queries? This would be a huge permissioning win.

This sounds good, but may be a fragile or dangerous way to create permissions. For a complex DB schema it may be difficult to see where some data might leak. It should be possible to compute the implicit permissions to show the admin, or even ensure that those don't change if the schema changes.

Just some thoughts

Any plans to implement blocking root level queries? This would be a huge permissioning win.

👌 this pretty much sums it up - a "simple" (obv I don't really know if it is, but I like to imagine it is :)) option to track a table so that it can be exposed over relations, etc, but not expose it at the root level, would dramatically simplify so much of the permissions we have to maintain today - like 10x improvement, we'd be able to drop most of them completely <3.

Is this RFC accepted? Is it on roadmap? I'm trying hasura and really liked it so far, but without this i will be forced to drop it

Any news on it?

This is very much needed.

From how it reads, it seems like release 2.8 might solve this (I have not tried the functionality yet, we're still on 2.1) - specifically #696. @tirumaraiselvan is that correct?

Yes, 2.8 solves this. We will merge this PR soon.

Merged via https://github.com/hasura/graphql-engine-mono/commit/f7f4e60250b4c7375a973d0e5770ac134217767a