Feature: Support for `extendedWhereUnique` preview feature

[StephanDecker]

Great package!

I am referering to fine-grained-access-control: https://prisma-appsync.vercel.app/advanced/securing-api.html#%F0%9F%91%89-fine-grained-access-control

I want to only allow access to update records when the username in our OIDC token is the same as in the database record. That's our code snippet:

shield: (params: QueryParams) => {
const claims = (params.identity as OPENID_CONNECT).claims;
const createdBy = { createdBy: claims?.preferred_username };
return {
 '{update,upsert,delete}/targetProfile{,/**}': {
        rule: createdBy, 
        reason: ({ model }) => `${model} can only be modified by ${claims?.preferred_username} .`,
        },
   };
}

We are getting the following error in our appsync lambda because the generated prisma type TargetProfileWhereUniqueInput exposes only unique fields:

From prima version 4.5 (by enabling the preview flag "extendedWhereUnique") the generated type exposes all fields on the model, not just unique fields.
It fails in the appsync lambda again because you must specify at least one unique field outside of the boolean operators AND, OR, NOT (see https://www.prisma.io/docs/reference/api-reference/prisma-client-reference#boolean-operators-with-userwhereuniqueinput)

It results in the following error message:

Could you support this or how could we use the shield functionality when we only update one unique record? Thanks for your support!

[maoosi]

Thanks @StephanDecker!

I'm usually not in favour of adding support for features that are still under the preview flag, as they add complexity to both implementation and testing.

That said, adding support for "extendedWhereUnique" would benefit quite a lot of use cases - so I'm not entirely close to the idea. Let me think about it, do some tests and come back to you on this!

[maoosi]

@StephanDecker Support for the extendedWhereUnique preview flag is ready and will be shipped as part of the coming 1.0.0-rc.5 release. This should allow you to use the shield rule outlined in your first message.