Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

fix: add granular read ops enum #2720

Open
wants to merge 1 commit into
base: main
Choose a base branch
from
Open

fix: add granular read ops enum #2720

Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
6 changes: 6 additions & 0 deletions Amplify/Categories/DataStore/Model/Internal/Schema/AuthRule.swift
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -22,6 +22,12 @@ public enum ModelOperation {
case update
case delete
case read
// granular read access
case `get`
case list
case sync
case listen
case search
Comment on lines 24 to +30
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I bet a lot of logic is determined by checking if the operation is .read and does something. Now that we allow compiling the more granular "read" types, that means all logic based on "read" should now be updated to

  1. If the previous check for read expected all granular read access then update the code to "if operation == read || operations.containsAll(list, sync, listen, search)"
  2. If the previous check for read expected just the sync API (for example DataStore's sync operation), then code can be updated to "if operation == read || operation == sync)"
  3. If previous check for read expected that the subscription API is used then --> "operation == read or operation == "listen"

}
Comment on lines +25 to 31
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Can we start off by attaching the generated Model swift types that utilizes these new granular read access cases? By doing so, we can update the source schema that we use to reference the generated types.

Is there an sort of relevant API calls that we can write, either in the unit or integration tests, utilizing these models, and asserting the expected behavior?

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The example schema using it is

type Todo @model
@auth(rules:[
  { allow: public, operations: [get, list, listen, sync, search] },
  { allow: owner }
])
{
  id: ID!
  name: String
}

The model files can be generated by the current version of modelgen, which has the following line generated

    model.authRules = [
      rule(allow: .public, operations: [.get, .list, .listen, .sync, .search]),
      rule(allow: .owner, ownerField: "owner", identityClaim: "cognito:username", provider: .userPools, operations: [.create, .update, .delete, .read])
    ]


/// - Warning: Although this has `public` access, it is intended for internal use and should not be used directly
Expand Down