Amplify-cli: Support ownerField as a list or string

[jkeys-ecg-nmsu]

Is your feature request related to a problem? Please describe.
Currently you can only assign a single ownerField as the owner of a given record. This makes sense from the perspective of starting fresh; but for those of us whose access patterns have changed over time, it makes sense to have the flexibility to add new fields to represent additional owners of the record.

Describe the solution you'd like
The GQL transformer should branch on whether the ownerField is a string or list/array, and preserve the current behavior for the former; else it should check all keys specified as string values passed into the ownerField list and authorize if any of the values match the identity.

Describe alternatives you've considered
Overriding resolvers to check additional ownerFields in an ad hoc fashion.

Additional context
This hampers the extensibility of GQL-generated resolvers.

[attilah]

@jkeys-ecg-nmsu this is doable, I think the same evaluation logic what we use for groups could be used. I marked it as an enhancement.

[forstmeier]

Hey, @attilah, is there an expected time frame for this functionality to be supported? @markwhitfeld have a similar use case outlined below:

type Task
  @model
  @auth(rules: [
      {allow: owner, provider: oidc, ownerField: "user", identityClaim: "sub", operations: [create, update, delete, read]},
      {allow: owner, provider: oidc, ownerField: "team", identityClaim: "teams", operations: [create, update, delete, read]}
    ])
{
  id: ID!
  title: String!
  user: String
  team: String
  description: String
  status: String
}

Here, "teams" would be a list from the provider of possible teams that the "team" value would have to match _at least one of_ in order to gain access. We've also run into some buggy behavior, based on using two owner rules together, similar to what was observed in #2241 but I'll ping that thread for more info.

[attilah]

@forstmeier currently it is not scheduled for the next 2 sprints, so I cannot share an ETA for this. If you'd like to do a PR for this, very welcome, we'll help if we can.

[jkeys-ecg-nmsu]

@forstmeier thank you very much for submitting the PR!

We'd like to begin testing / take advantage of this feature right away. @attilah any timeline on integration of John's PR or how I can help move this along (e.g. how can I improve the PR)?

[forstmeier]

Hey, @jkeys-ecg-nmsu which PR are you referring to? I don't believe I've opened one up yet.

[araker]

Just came across this limitation in the @auth directive. My use case is the same as the topic starter, having a dynamic list of owners for a certain record/resource.