Add AffectedArg-decorator

[fraxachun]

Current situation is that when a scope-argument is present in a graphql-request this is used to check the content scope. However, in certain situations (e.g. the ContentScope only has one field) we just want to submit the value instead of a scope-Object:

    @Query(() => Customers)
    @AffectedArg((tenantId: string) => ({tenantId}))
    async customersForTenant(@Args("tenantId") tenantId: string): Promise<PaginatedNews> {

[nsams]

please add usage examples to the description of this PR

[nsams]

Why not use @AffectedEntity(Teanent, { idArg: "teanentId"}); together with @ScopedEntity in Teanent entity?

[fraxachun]

Why not use @AffectedEntity(Teanent, { idArg: "teanentId"}); together with @ScopedEntity in Teanent entity?

You're right, this accomplishes the same and in the end is more logical.

[johnnyomair]

Wasn't our intention to remove the scope arg magic and make it explicit? Something like @AffectedArg("scope")?

[fraxachun]

Wasn't our intention to remove the scope arg magic and make it explicit? Something like @AffectedArg("scope")?

Initially yes. But I can't think of a case where you want to change the name of the scope-argument without having an affected entity. Do you?

Because if not I think it's sufficient to just let the dev know when it's missing: https://github.com/vivid-planet/comet/blob/main/packages/api/cms-api/src/user-permissions/auth/user-permissions.guard.ts#L46

[johnnyomair]

Do you?

No.

The "problem" that still remains that if developers send a scope arg, they may assume that everything is validated correctly, where it may not be. For example:

updateTenant(
  scope: { tenantId: "123" }, // ID of the parent tenant
  id: "456" // Actual ID of the tenant
)

This operation will be allowed if a user has access to the parent tenant, but will not verify if a user can access the child tenant. I thought this is what we we're talking about last week.