Question about users system

[Eduardo Leones]

Good Morning.

First, excuse my English, I hope to have been understood my question.

I'm new in this Django world. My question is more theoretical because I have little coded thing in the project.

I am developing a system in which my clients are companies. Every company needs to have its isolated from other business data.

My reasoning is to register each client (company) as a group within the Django auth system. Users of them would be users connected to this group.

This line of thinking is correct? There is a decorators to limit access to the Group as a whole? In part of the Model link the data to a group is a good practice?

Well there are many questions, more than all converge on the best way to use the Django users system for this type of need.

thank you,

[Javier Guerra Giraldez]

On 15 April 2016 at 12:17, Eduardo Leones <edu...@ypytecnologia.com.br> wrote:
> I am developing a system in which my clients are companies. Every company
> needs to have its isolated from other business data.

google for "multi-tenant" web applications. warning: there are quite
strong opinions about how it should be done.

in particular, there's lots of advice of setting a separate database
for each tenant. It does have some advantages, but in practice it's
not easy to do in Django.

> My reasoning is to register each client (company) as a group within the
> Django auth system. Users of them would be users connected to this group.

Yes, this can work. Personally, instead of reusing the Group tabke, I
tend to create a specific 'Company' table, and add a 'company' foreign
key to users. The reasoning is that you _will_ have other groups that
are not companies (maybe internal divisions, or for access-level
privileges, whatever), and then you have the problem of separating two
kinds of groups.

> This line of thinking is correct? There is a decorators to limit access to
> the Group as a whole? In part of the Model link the data to a group is a
> good practice?

Make sure that every record can be traced to a specific Company, some
of them because they're linked to a User, or maybe by a direct
'company' link. Then be _absolutely_ sure that every database query
includes a company condition.

something like this:

@login_required
def getsomething(request, id):
thing = get_object_or_404(Thing,
department__company=request.user.company, id=id)
.... build response ...


It's tempting to put the "current" company somewhere and patch all
requests to include that, but it gets very complex quickly, and also
you get the problem of managing what in effect is a global variable.
not worth it.


--
Javier

[Eduardo Leones]

Javier, thanks for the answer.

Very interesting "multi-Tenat" solution, including found this really cool below:

https://github.com/bernardopires/django-tenant-schemas

What worried me was his observation that is not a simple implementation to be done in Django. What is the biggest difficulty in this method?

I think your suggestion to create a separate table for fantastic company and I think the best solution at the moment.

tks

[Luis Zárate]

I thing Sites framework do something similiar to you problem, so you could study how is implemented.


https://docs.djangoproject.com/en/1.9/ref/contrib/sites/

> --
> You received this message because you are subscribed to the Google Groups "Django users" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to django-users...@googlegroups.com.
> To post to this group, send email to django...@googlegroups.com.
> Visit this group at https://groups.google.com/group/django-users.
> To view this discussion on the web visit https://groups.google.com/d/msgid/django-users/89dad6b7-4967-48af-8554-e1a53f2d584f%40googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>

--

"La utopía sirve para caminar" Fernando Birri