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/ El viernes, 15 de abril de 2016, Eduardo Leones < edua...@ypytecnologia.com.br> escribió: > 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 > > Em sexta-feira, 15 de abril de 2016 10:27:43 UTC-3, Javier Guerra escreveu: >> >> 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 > > -- > 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+unsubscr...@googlegroups.com. > To post to this group, send email to django-users@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 -- 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+unsubscr...@googlegroups.com. To post to this group, send email to django-users@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/CAG%2B5VyNMsnNqRK2g%2BB2-JThE2dbAkzShUBF%3DuTjBGKwixNM-Kw%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
