Forum Discussion
When you say "User," this is someone who has been given a Quickbase User account in your app (vs. the "Everyone On The Internet" Role), right? Put another way, are you able to distinguish which User is logged in?
If you are authenticating Users, it seems like you'd create a custom Role for Customers and use the native QB Access restrict visibility as necessary. For example, a given record is viewable where the logged in User matches the User stored on the Order. Then, you'd apply this same access logic to both the parent and the child by looking up the parent's stored User on the child.
Sometimes, when logic becomes complex or needs to be reused throughout the app, I'll create a Formula Checkbox called "Viewable" that evaluates to true under the right conditions, otherwise, it defaults to false (not viewable). Then, you could place this Formula Checkbox on the parent and pass it to the children as necessary. This keeps your "code" DRY and in sync across tables.
Or perhaps you could leverage Formula Queries with overridden sub-field access vs. lookups (untested)? Or leverage native QB emails with a "more minimal" custom form included, then trigger the email send when an order is created or updated (instead of the User logging in)? The only other way that comes to mind at the moment would be to create a Customer Portal with further authentication and authorization logic and use the API to to pull in Order data … but, I imagine that's a heavier lift than you were hoping for!
------------------------------
Brian Seymour
------------------------------