Ability to pre-filter items shown in lists (overviews)

[NoTuxNoBux]

Maybe I'm overlooking this, but I have been digging into the documentation and code of Keystone 6 to find a way on how to pre-filter specific rows in lists (overviews). My use case is that some users may not see other users in the list due to privacy concerns (GDPR) as that would allow them to infer what other companies have users in our system.

It seems possible to attach access control checks to operation read, but an itemId never seems to be passed here to govern preventing reading of specific users, making it only possible to govern access to the whole set of records using this. It seems to be possible to get somewhat close by hiding grid columns and fields based on the user, but this is far from ideal.

I see a couple of options that could work:

• The access control API can be used with operation read and a specific itemId when an item is being opened. This would also be used for the list overview to filter out items a user may not see. This is the most intuitive, but probably wouldn't scale well as access control is implemented in TypeScript and the overview is backed by a GraphQL query.
• It would be possible to set a custom or override the GraphQL query that is used for the overview where you also have access to the context (i.e. the session, user logged in, ...). This might be easiest since this view is already backed by a GraphQL query, and scales well, it is more error-prone to get this right for the developer, though.
• Same as above, but add a method that allows returning the items to display in the overview, which implies the user has to write and execute the GraphQL query to fetch the items to display himself. The additional advantage is that you can also fetch the items to display from some other source.
• Make a custom admin view, but it doesn't appear to be possible to pass a custom query, so this seems pretty involved for this goal.

Since there are also filters displayed in the overview itself, the "pre-filters" configured by the developer may not be toggled by the user and must complement the filters the users add. They also need to be able to block direct API access to these users somehow - otherwise you can circumvent the front end by using the API directly.

Keystone is pretty flexible so far, and I am fairly new to it, so it seems more likely that I just don't see it.

[gautamsi]

Since there are also filters displayed in the overview itself, the "pre-filters" configured by the developer may not be toggled by the user and must complement the filters the users add. They also need to be able to block direct API access to these users somehow - otherwise you can circumvent the front end by using the API directly.

what you want is exactly the access control for read and not something else, unless you implement at graphql layer it will be possible to circumvent it using api. Also it may be needed for your app so that people can query and see other user profile in that case you can not restrict it using the pre canned query filter

[NoTuxNoBux]

Indeed.

I also recently tried to achieve this by using Prisma middleware, which seemed like a promising workaround, but unfortunately context.session seems to still be empty when db.onConnect is invoked and remains empty during middleware invocation, so I cannot retrieve the currently logged in user to use it to filter the queries. I can't find any other point to hook into Keystone to get access to that data either - I'm guessing the database connection is made before any authentication is done (possibly because the user might need to be retrieved from the database in order to validate if the record still exists during authentication).