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.dhak...@gmail.com> 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+unsubscr...@googlegroups.com.
> 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.
