Milia issue with seed_fu about milia HOT 3 CLOSED

Before you can set the current_tenant, there must be an authorized
current_user and that user must have access to the tenants being used in
Tenant.set_current_tenant. That access is established via the HABTM join
table: tenants_users. Thus if you haven't set that up correctly with your
seed_fu, the exception will be raised. I don't think the previous milia
version was properly checking this.

best, Daudi
On Dec 30, 2013 12:42 AM, "Shaabi" [email protected] wrote:

Hi there,

I'm really looking forward to the new milia gem with rails 4 and devise 3
support!

I was testing out the best and ran into an issue, I am using the seed_fu
gem to populate default tenant data in the following manner, which was
working with Milia 0.3.30

e.g. in a single file

Tenant.set_current_tenant Tenant.where(:name => 'First').first

Domain.seed_once(:uri,
{:uri => 'testing1.com'},
{:uri => 'testing2.com'}
)

Tenant.set_current_tenant Tenant.where(:name => 'Second').first

Domain.seed_once(:uri,
{:uri => 'testing3.com', :primary => true}
)

Now it throws an
Milia::Control::InvalidTenantAccess (Domain.rb uses acts_as_tenant)

I get the same behaviour when trying this via the rails console, even
though Tenant.current_tenant shows the correct one is selected, it fails
exactly on base.rb:31 since the tenant_id check fails.

I went through the seed_fu src to see what it was doing,
It does a Record.new followed by assign_attributes then save which when
run in that sequence in the console works just fine. confused :?

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/12
.

from milia.

Hi Thanks for the reply, I see what you mean though I'm not sure how I could auth (or fake) a logged in devise user from a rake task, would it make sense to allow setting tenants without users when being run via the console or rake tasks ?

Though what I dont get is that, in the console if I do a
set_current_tenant + Model.new + assign_attributes +save it still allows me to save the record without having an authorised user but seed_once fails with invalid access even though it is also doing just the above. I feel as though it might be a different cause to the error ?

from milia.

Please see the README, towards the end or latter part. It addresses this
issue for both console, rake, and testing for how to manually sign in a
user.

Specifically (quoted from README)

console

Note that even when running the console, ($ rails console) it will be run in multi-tenanting mode. You will need to establish a current_user and setup the current_tenant, otherwise most Model DB accesses will fail.

For the author's own application, I have set up a small ruby file which I load when I start the console. This does the following:

    def change_tenant(my_id,my_tenant_id)
      @me = User.find( my_id )
      @w  = Tenant.find( my_tenant_id )
      Tenant.set_current_tenant @w
    end

change_tenant(1,1)   # or whatever is an appropriate starting user, tenant

Now if you are only doing a rake task, or working in the console, then this should be sufficient (that is, not setting a current_user). But if you are doing anything which involves controllers, current_user will need to be established using devise methods.

I have yet to test this in the beta-3 version, however, so if you run into difficulty, let me know.

best, Daudi
On Dec 30, 2013 1:46 AM, "Shaabi" [email protected] wrote:

Hi Thanks for the reply, I see what you mean though I'm not sure how I
could auth (or fake) a logged in devise user from a rake task, would it
make sense to allow setting tenants without users when being run via the
console or rake tasks ?

Though what I dont get is that, in the console if I do a
set_current_tenant + Model.new + assign_attributes +save it still allows
me to save the record without having an authorised user but seed_once fails
with invalid access even though it is also doing just the above. I feel as
though it might be a different cause to the error ?

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/12#issuecomment-31339046
.

from milia.