Set tenant within read action in resource dsl?
Hi, is it possible to set the tenant within a read action in the Resource DSL?
I tried to call
set_tenant/1
in there but it doesn't seem to work...20 Replies
It should be 🙂 What exactly are you doing? Where does the tenant come from? Or is it a static value?
I'm trying to pass the tenant in via an argument to the action (it's a bit of a temporary hack to debug something else actually)
Does something like this not work?
sorry I forgot you could use anonymous fns like that within the DSL. Yep that worked - thank you! 👍🏼
@Zach Daniel Actually, I'm not sure whether this is working or not.
Basically I have two related resources - one (
TenantedResource
) has context tenancy and the other resource (UntenantedResource
) doesn't have tenancy.
I'm trying to make a query action on UntenantedResource
to load some related records of TenantedResource
.
The query works when I call the action from UntenantedResource
's api, specifying the tenant.
However when I try and call it via a graphql query and pass the tenant in as an argument, I'm getting errors like:
🤔 interesting.
The use case should be supported. What is the stacktrace of your error?
actually I think it's an ash_graphql error
when I remove the
tenant: tenant
from the call to UntenantedResource
's api, but keep the tenant
argument, it still worksdo you have other multitenant stuff working in AshGraphql currently?
Or is this your first time setting it up
actually I just have resources without multitenancy working on the graphql api at the moment - so yes it might be the first multitenant stuff I've done with ash graphql
Gotcha, okay. Not quite sure what is going wrong yet, but lets start at the basics. Do you want to be setting multitenancy as an argument? Typically this would be set either in a subdomain, or a path, that kind of thing.
Its okay for a tenant to be set when referring to a non-multitenant resource generally
ultimately, I don't want to be setting multitenancy as an argument. But for now it's just convenient for testing things out quickly without making decisions about all that stuff
gotcha. Well, it should be convenient 😆
So what is the stacktrace of the error?
it's actually just a stop-gap temporary API that we need to spin up fairly quickly
the related resource is loaded through a many_to_many relationship
🤔 very interesting.
Is the join resource multitenant?
Okay, first things first though. Can you confirm that:
doesn't raise the same error?
okay, I think I found the issue actually
Yes - The join resource is multi tenant too
Well, I've definitely found at least one/a main issue
I’ve just left my computer, but I’m pretty sure that
Works (probably after adding a tenant option) because when I call the action directly from the untenanted resource api it works
Yeah, I should have a fix for this in main shortly
Although the join resource having a tenant may make your life difficult, as we don't currently provide a way to set arguments on the read action of a join resource
so doing tenancy that way may be problematic 😦
So either we need to find a way to allow you to specify arguments that belong on the join resource action, and then specify a way to ferry those through in Ash, or you'll want to use a header or something like that for tenancy to sidestep this current issue. Or you'll need a workaround using something like calculations.
I've pushed my "fix", but I'm pretty sure the very next error you're going to get is "TenantedJoinResource requires a tenant"
Ah ok, thanks! Using a header for tenancy probably makes more sense in our context anyway, so I’ll try that if I come across an error
Definitely open to ideas on improving "mixed tenancy" like this, as you've highlighted some inconveniences around join tables (and of course the bug you found).
I expect this was a probably pretty weird edge case though - trying to access a tenanted resource through an untenanted one... However it's working perfectly now, setting the tenant via a header - thank you!