Hi Jim,
        That makes sense. I will check it out on which option to go. 
Thanks! for all the guidance. 

Thank you,

*Rahul Dhakate*

On Wednesday, October 17, 2018 at 7:57:32 PM UTC+5:30, Jim S wrote:
>
> Rahul
>
> First, what I was referring to was common_filters, not common fields.  
> Here is the scenario as I see it.
>
> In you auth_user table you have a workspace field.  Then in other tables 
> that are workspace-specific you also have a workspace field to show which 
> workspace they relate to
>
> Here is how I think I would handle it, assuming I am understanding your 
> need.  And, assuming that the workspace identifier is stored on the user 
> record.  You wouldn't gather it on the login page.
>
> In db.py I'd have code that would check to see if the user is logged in.  
> If so, then set the common filters for the workspace-specific tables
>
> if auth.is_logged_in:
>>     db.related_table_1._common_filter = lambda query: 
>> db.related_table_1.workspace = auth.user.workspace
>>     db.related_table_2._common_filter = lambda query: 
>> db.related_table_2.workspace = auth.user.workspace
>>     db.related_table_3._common_filter = lambda query: 
>> db.related_table_3.workspace = auth.user.workspace
>>     db.related_table_4._common_filter = lambda query: 
>> db.related_table_4.workspace = auth.user.workspace
>>     ...etc...
>
>
> Make sense?
>
> Anyone else out there that's done this and can show a better way?  
>
> -Jim
>
>
> NOTE - you might also skip the common filters if you're logging in as an 
> admin.  Then you might want to see data for all workspaces
>
> NOTE 2 - If you really want people to specify their workspace when they 
> login (meaning they have access to all of them but they choose which one on 
> login) then you'd have to override the default login code to gather that 
> extra variable and store it in your session somewhere.  Then use that 
> instead of auth.user.workspace when building your filters.
>
>
>
> On Wed, Oct 17, 2018 at 2:06 AM Rahul <rahul....@gmail.com <javascript:>> 
> wrote:
>
>> Hi Jim,
>>           I am afraid no I didn't check that section but I just finished 
>> reading it. Thanks! for directing me to it. Looks like a new addition to 
>> DAL (might be a couple of versions back) & looks promising. So now, we can 
>> specify something like request_tenant using db._common_fields  field 
>> parameter. 
>>
>> I would need it for all tables so is there a specific syntax like below 
>> that I am required to specify in each table I create ?
>>
>> db._common_fields.append(Field('request_tenant',
>>                                default=request.env.http_host,
>>                                writable=False))
>>
>>
>> Also, can we set the default value to a field value that we can query or 
>> pass as a session variable like session.workspace == 'some workspace name'  
>> while the user logs in ? 
>>
>> default=session.workspace,
>>
>>
>> If yes - what do I need to modify to add this additional field in Auth so 
>> it will be an input field for the user to key in the workspace name. Then I 
>> can store this workspace in session variable and use it. The reason is I 
>> want a group of users (accessing the same app and database from different 
>> locations) belonging to same workspace.  This is how they are grouped. 
>> please see the screenshot posted from my actual application login. In it I 
>> use workspace name as well to validate but after reading the book seems 
>> like we would not require workspace for validation if we can have the user 
>> provide the field for redirection and for us to grab the session variable. 
>>
>> Or is this not needed at all after we use common fields ?  
>>
>> I hope I am clear and make sense  :-) 
>>
>> Regards,
>>
>> Rahul
>>
>>
>>
>>
>>
>> On Tuesday, October 16, 2018 at 7:49:49 PM UTC+5:30, Jim S wrote:
>>>
>>> Have you looked at common filters?
>>>
>>>
>>> http://web2py.com/books/default/chapter/29/06/the-database-abstraction-layer?search=common+filter#Common-filters
>>>
>>> -Jim
>>>
>>> On Tuesday, October 16, 2018 at 7:35:04 AM UTC-5, Rahul wrote:
>>>>
>>>> Hey Everyone,
>>>>        Greetings! I have a question. I went through Auth documentation 
>>>> and understood that we can add extra fields to the Auth tables. However, I 
>>>> still want to be a little more clear to achieve below - I am currently 
>>>> using three fields for a multi-tenant system like workspace, username and 
>>>> password. Here workspace depicts where the user belongs to (see 
>>>> explanation 
>>>> in Q1 below) I am currently using my own code to manage this stuff 
>>>> manually 
>>>> (almost everything that auth does), now though I want to give Auth a try 
>>>> and tailor it to fit my needs. I dont want to maintain that amount of code 
>>>> and use the existing API. Can I get help on achieving that in the simplest 
>>>> way. If it works, I would switch to using Auth 
>>>>
>>>> * Q1]* How can we use Auth to add one more extra field for 
>>>> authentication when I want a system to validate login based on three 
>>>> parameters like - Validation needs to be done based on all three 
>>>> parameters 
>>>> specified. For each application I can use 'n' number of unique workspaces 
>>>> and 'n' number of users would belong to these workspaces. How to do this ?
>>>>
>>>>    1. *workspace *- An alpha numeric field that would store a unique 
>>>>    name denoting users belonging to a particular set   (For example users 
>>>>    working in a specific  location like los-angeles or washington)  or an 
>>>>    office location like michigan, nevada or Zones like north, south  .. 
>>>>    sort-of etc. )
>>>>    2. *username *- Its available already 
>>>>    3. *password *- Its available already
>>>>    
>>>>
>>>> *Q2]* Which all tables need to be modified ? 
>>>>
>>>> *Q3] *Any changes in any other code in any files ? 
>>>>
>>>> I know I can clone my app multiple times and support multi-tenancy 
>>>> however, if this can be achieved with Auth - that would be great. 
>>>>
>>>> Regards,
>>>>
>>>> *Rahul *
>>>>
>>> -- 
>> Resources:
>> - http://web2py.com
>> - http://web2py.com/book (Documentation)
>> - http://github.com/web2py/web2py (Source code)
>> - https://code.google.com/p/web2py/issues/list (Report Issues)
>> --- 
>> You received this message because you are subscribed to a topic in the 
>> Google Groups "web2py-users" group.
>> To unsubscribe from this topic, visit 
>> https://groups.google.com/d/topic/web2py/6SscBvMorU0/unsubscribe.
>> To unsubscribe from this group and all its topics, send an email to 
>> web2py+un...@googlegroups.com <javascript:>.
>> For more options, visit https://groups.google.com/d/optout.
>>
>

-- 
Resources:
- http://web2py.com
- http://web2py.com/book (Documentation)
- http://github.com/web2py/web2py (Source code)
- https://code.google.com/p/web2py/issues/list (Report Issues)
--- 
You received this message because you are subscribed to the Google Groups 
"web2py-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to web2py+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Reply via email to