yetitwo
04/18/2024, 7:55 PMJoey
04/18/2024, 8:09 PMJoey
04/18/2024, 8:09 PMJoey
04/18/2024, 8:09 PM6up.oeb
04/18/2024, 8:36 PMgsinghds_56997
04/18/2024, 9:59 PMJoey
04/18/2024, 10:05 PMgsinghds_56997
04/18/2024, 10:05 PMJoey
04/18/2024, 10:06 PMJoey
04/18/2024, 10:06 PMJoey
04/18/2024, 10:06 PMgsinghds_56997
04/18/2024, 10:07 PMgsinghds_56997
04/18/2024, 10:07 PMgsinghds_56997
04/18/2024, 10:07 PMgsinghds_56997
04/18/2024, 10:08 PMJoey
04/18/2024, 10:10 PMJoey
04/18/2024, 10:10 PMJoey
04/18/2024, 10:10 PMgsinghds_56997
04/18/2024, 10:12 PMJoey
04/18/2024, 10:15 PM6up.oeb
04/18/2024, 10:19 PMJoey
04/18/2024, 10:22 PMJoey
04/18/2024, 10:22 PMalechenninger
04/19/2024, 5:39 PMview_notification = view & notification_subscriber
(where notification subscriber could be a synthetic relation with a subscription inherited from somewhere else in the graph). The team likes this because it solves an otherwise nasty query of potentially getting a bunch of users with access, and then having to join that with their own data on who is subscribed. (We could also easily do things like refer to other relations e.g. user groups when managing subscribers).
On one hand, I don't see anything wrong with this โย it seems to fit the underlying graph model very well. On the other hand one can argue it's not strictly access * so are we abusing something. Curious for anyone's thoughts or experience with this kind of situation :).
\* I can actually think of this like access where you're authorizing your own "inbox" ... but perhaps that is too creative :).Joey
04/19/2024, 5:40 PMJoey
04/19/2024, 5:40 PMalechenninger
04/19/2024, 5:41 PMalechenninger
04/19/2024, 5:41 PMsmuzzy_waiii
04/20/2024, 10:47 AMsmuzzy_waiii
04/20/2024, 10:47 AM