Model Fields without read access should be marked 'isReadOnly'

[cherrydev]

Before opening, please confirm:

• [X] I have installed the latest version of the Amplify CLI (see above), and confirmed that the issue still persists.
• [X] I have searched for duplicate or closed issues.
• [X] I have read the guide for submitting bug reports.
• [X] I have done my best to include a minimal, self-contained set of instructions for consistently reproducing the issue.

How did you install the Amplify CLI?

No response

If applicable, what version of Node.js are you using?

No response

Amplify CLI Version

8.0.2

What operating system are you using?

Mac

Amplify Codegen Command

Not applicable

Describe the bug

When a graphql schema model and fields have @auth rules on it indicating that some of the model fields are not writable (don't have an update operation in the @auth rules) the generated fields are not marked with isReadOnly. Right now, this is the cause of aws-amplify/amplify-category-api#230 . Currently, any model that has read-only fields in it is completely incompatible with Datastore, as it will generate update statements that include the non-writable fields, causing AppSync to reject the update. (Now, whether AppSync should just ignore read-only fields that are exactly the same as the current values rather than rejecting it is another argument).

Expected behavior

I would expect that when there are @auth statements on a model that indicate that some fields are read-only, those fields should be marked with the isReadOnly flag in the code-gen.

Reproduction steps

This is trivially verified by looking at the getWritableFields function in appsync-modelgen-plugin/src/visitors/appsync-java-visitor.ts as the only fields it excludes as being writable are connected fields.

The schema below shows an example of a model object that is, by default, read-only, but has a field called readWriteField which has an @auth rule indicating that the field can be modified.

Please note that the id or other key field should not be marked as isReadOnly as that will prevent the graphql query generators in the client libraries from including them in the input variable of the query.

GraphQL schema(s)

@auth(rules: [{allow: owner, operations: [read], provider: userPools, ownerField: "userId"}])
{
  id: ID! @auth(rules: [{ allow: owner, operations: [read, update], provider: userPools, ownerField: "userId"}])
  userId: ID!
  readOnlyField: String!
  readWriteField: String! @auth(rules: [{ allow: owner, operations: [read, update], provider: userPools, ownerField: "userId"}])
}

Log output

No response

Additional information

Right now the work-around I'm using is to manually modify the generated client model files to mark the appropriate fields as isReadOnly.

[ykethan]

Hey @alice-was-here, thank you for reaching out. Could you provide us the following information.

1. Project identifier output when running amplify diagnose --send-report
2. Could you verify if the team-provider-info.json and amplify-meta.json contain the UnauthRoleName parameter.
3. type of API created in the project, is this is a GraphQL API or REST API?

[alice-was-here]

1. Identifier: 041877376e08b4e55ad7371782ce979b
2. Yes, both files contain the UnauthRoleName param.
3. It is a graphql api.

[ykethan]

Hey @alice-was-here, thank you for the information. On diving into the files noticed the parameters.json under the api/<api-name>/build folder contains the following

 "authRoleName": {
    "Ref": "AuthRoleName"
  },

but the parameters.json at the api/<api-name> root folder does not contain this. Transferring the issue to our API repository for better assistance.

[AnilMaktala]

Hey @alice-was-here, Are you still experiencing this issue or blocked by this issue?

[AnilMaktala]

Hey 👋 , This issue is being closed due to inactivity. If you are still experiencing the same problem and need further assistance, please feel free to leave a comment. This will enable us to reopen the issue and provide you with the necessary support.

[github-actions[bot]]

This issue is now closed. Comments on closed issues are hard for our team to see. If you need more assistance, please open a new issue that references this one.