User to UserProfile access problem

[Mike Dewhirst]

Using Django 1.10 Admin with a legacy contrib.auth.user plus 1:1 userprofile

It works fine but I'm having trouble letting the user adjust their name 
and email address in contrib.auth.user.


Additionally, I reveal some of the user profile fields as an Admin 
inline under the Company model for users to edit their preferences.


I would like to include a view which incorporates selected fields from 
both models as a single inline under Company in the Admin. Is that 
possible? Should I instead retrofit a custom user?


Thanks

Mike

--
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/b8f38ada-fa02-19bd-1987-6aad86d06773%40dewhirst.com.au.
For more options, visit https://groups.google.com/d/optout.

Re: Row based permissions: In DB or App? ... farewell pain

[James Schneider]

On Aug 3, 2017 1:08 AM, "guettli"  wrote:

First I asked a similar question on the postgresql-general list. The
discussion[1] has settled there.

Now I would love the hear what you think.


I am thinking about rewriting an existing application which uses
PostgreSQL via Django.

Up to now the permission checks are done at the application level.

Up to now queries like: "Show all items which the current user is
allowed to modify" result in complicated SQL and
this leads to slow queries.

Up to now there is one db-user and the application does the filtering
of rows to prevent application users to see
items which they are not allowed to see.

I guess most web applications work like this.

I would like to reduce the "ifing and elsing" in my python code (less
conditions, less bugs, more SQL, more performance)
One important intention for me: I would like to avoid the redundancy.
As soon as I want to query for
"Show all items which the current user is allowed to modify" I need
the permission checking in a SQL WHERE condition.

If I implement this. Then my code which might look like this is redundant:

{{{

def has_perm(obj, user):
if user.is_superuser:
return True
...

}}}


Yes, I feel farewell pain. I love Python, but I guess I will use perm
checking via SQL WHERE for new projects in the future.

What do you think?

 Regards,
   Thomas Güttler

[1]: 
https://www.postgresql.org/message-id/e662fd8a-6001-514c-71e8-01718444f338%40thomas-guettler.de

I thumbed through the threads on the PG list, and the best summary of the
answers you received is:

A. Yes you can probably do that, but it would likely be extremely
complicated and Django won't necessarily make it easy.

B. The "problem" you are trying to solve is more of a "preference" with a
questionable motive of speed increases.


There wasn't a great amount of support for what you are trying to do, and I
doubt you'll find much on this list.

The DB should not be responsible for business logic (in this case,
authorization rules). DB's are only good at storing, searching, and
returning data. Data doesn't care who you are, nor does the DBMS past the
table level in most cases.

There are several other points to consider.

- By moving this logic in to the DB, you are almost certainly vendor
locking yourself to the DB. If your project is not distributed to others,
then it may not be an issue. If you do, abstract away the function calls as
much as possible to build an internal Python API. If you need to change the
underlying database functionality later, your application code should
remain relatively untouched, and you can send the bundle of money in labor
you saved to me. ;-)

- You'll almost certainly take a performance hit when connecting to the
database. If each connection to the DB is using a different user, then you
likely cannot take advantage of things like DB connection pooling. Every
request would require that a connection be built, utilized, and then torn
down. Those operations have a cost in both time and resources.

- It likely won't scale well. Assuming you have a fair number of unique
users with concurrent connections (depending on the resources available and
tuning, this could be as little as a few dozen), your DB now has to manage
at least a single connection or

-- 
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/CA%2Be%2BciV1obpdOUpLdMQ9jwYgLOjisUcUmVbFfHOv8qKE4EQPmA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Row based permissions: In DB or App? ... farewell pain

[Antonis Christofides]

Hi,

> - You'll almost certainly take a performance hit when connecting to the
> database. If each connection to the DB is using a different user, then you
> likely cannot take advantage of things like DB connection pooling. Every
> request would require that a connection be built, utilized, and then torn
> down. Those operations have a cost in both time and resources.
>
> - It likely won't scale well. Assuming you have a fair number of unique users
> with concurrent connections (depending on the resources available and tuning,
> this could be as little as a few dozen), your DB now has to manage at least a
> single connection or
Not necessarily. Django could connect to the db as a PostgreSQL superuser and
middle that runs very early could use "set session authorization" to switch 
user.

Regards,

Antonis

Antonis Christofides
http://djangodeployment.com

On 2017-08-09 11:03, James Schneider wrote:
>
>
> On Aug 3, 2017 1:08 AM, "guettli"  > wrote:
>
> First I asked a similar question on the postgresql-general list. The 
> discussion[1] has settled there.
>
> Now I would love the hear what you think.
>
>
> I am thinking about rewriting an existing application which uses 
> PostgreSQL via Django.
>
> Up to now the permission checks are done at the application level.
>
> Up to now queries like: "Show all items which the current user is allowed 
> to modify" result in complicated SQL and
> this leads to slow queries.
>
> Up to now there is one db-user and the application does the filtering of 
> rows to prevent application users to see
> items which they are not allowed to see.
>
> I guess most web applications work like this.
>
> I would like to reduce the "ifing and elsing" in my python code (less 
> conditions, less bugs, more SQL, more performance)
>
> One important intention for me: I would like to avoid the redundancy. As 
> soon as I want to query for 
> "Show all items which the current user is allowed to modify" I need the 
> permission checking in a SQL WHERE condition.
>
> If I implement this. Then my code which might look like this is redundant:
>
> {{{
>
> def has_perm(obj, user):
> if user.is_superuser:
> return True
> ...
>
> }}}
>
>
> Yes, I feel farewell pain. I love Python, but I guess I will use perm 
> checking via SQL
> WHERE for new projects in the future. What do you think?  Regards,
>Thomas Güttler
>
> [1]: 
> https://www.postgresql.org/message-id/e662fd8a-6001-514c-71e8-01718444f338%40thomas-guettler.de
> 
> 
>
> I thumbed through the threads on the PG list, and the best summary of the
> answers you received is:
>
> A. Yes you can probably do that, but it would likely be extremely complicated
> and Django won't necessarily make it easy.
>
> B. The "problem" you are trying to solve is more of a "preference" with a
> questionable motive of speed increases.
>
>
> There wasn't a great amount of support for what you are trying to do, and I
> doubt you'll find much on this list.
>
> The DB should not be responsible for business logic (in this case,
> authorization rules). DB's are only good at storing, searching, and returning
> data. Data doesn't care who you are, nor does the DBMS past the table level in
> most cases.
>
> There are several other points to consider. 
>
> - By moving this logic in to the DB, you are almost certainly vendor locking
> yourself to the DB. If your project is not distributed to others, then it may
> not be an issue. If you do, abstract away the function calls as much as
> possible to build an internal Python API. If you need to change the underlying
> database functionality later, your application code should remain relatively
> untouched, and you can send the bundle of money in labor you saved to me. ;-)
>
> - You'll almost certainly take a performance hit when connecting to the
> database. If each connection to the DB is using a different user, then you
> likely cannot take advantage of things like DB connection pooling. Every
> request would require that a connection be built, utilized, and then torn
> down. Those operations have a cost in both time and resources.
>
> - It likely won't scale well. Assuming you have a fair number of unique users
> with concurrent connections (depending on the resources available and tuning,
> this could be as little as a few dozen), your DB now has to manage at least a
> single connection or
>
>
> -- 
> 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
> .
> V

Re: Row based permissions: In DB or App? ... farewell pain

[Antonis Christofides]

> middle that runs very early
middleware

Antonis Christofides
http://djangodeployment.com

On 2017-08-09 11:15, Antonis Christofides wrote:
>
> Hi,
>
>> - You'll almost certainly take a performance hit when connecting to the
>> database. If each connection to the DB is using a different user, then you
>> likely cannot take advantage of things like DB connection pooling. Every
>> request would require that a connection be built, utilized, and then torn
>> down. Those operations have a cost in both time and resources.
>>
>> - It likely won't scale well. Assuming you have a fair number of unique users
>> with concurrent connections (depending on the resources available and tuning,
>> this could be as little as a few dozen), your DB now has to manage at least a
>> single connection or
> Not necessarily. Django could connect to the db as a PostgreSQL superuser and
> middle that runs very early could use "set session authorization" to switch 
> user.
>
> Regards,
>
> Antonis
>
> Antonis Christofides
> http://djangodeployment.com
> On 2017-08-09 11:03, James Schneider wrote:
>>
>>
>> On Aug 3, 2017 1:08 AM, "guettli" > > wrote:
>>
>> First I asked a similar question on the postgresql-general list. The 
>> discussion[1] has settled there.
>>
>> Now I would love the hear what you think.
>>
>>
>> I am thinking about rewriting an existing application which uses 
>> PostgreSQL via Django.
>>
>> Up to now the permission checks are done at the application level.
>>
>> Up to now queries like: "Show all items which the current user is 
>> allowed to modify" result in complicated SQL and
>> this leads to slow queries.
>>
>> Up to now there is one db-user and the application does the filtering of 
>> rows to prevent application users to see
>> items which they are not allowed to see.
>>
>> I guess most web applications work like this.
>>
>> I would like to reduce the "ifing and elsing" in my python code (less 
>> conditions, less bugs, more SQL, more performance)
>>
>> One important intention for me: I would like to avoid the redundancy. As 
>> soon as I want to query for 
>> "Show all items which the current user is allowed to modify" I need the 
>> permission checking in a SQL WHERE condition.
>>
>> If I implement this. Then my code which might look like this is 
>> redundant:
>>
>> {{{
>>
>> def has_perm(obj, user):
>> if user.is_superuser:
>> return True
>> ...
>>
>> }}}
>>
>>
>> Yes, I feel farewell pain. I love Python, but I guess I will use perm 
>> checking via SQL
>> WHERE for new projects in the future. What do you think?  Regards,
>>Thomas Güttler
>>
>> [1]: 
>> https://www.postgresql.org/message-id/e662fd8a-6001-514c-71e8-01718444f338%40thomas-guettler.de
>> 
>> 
>>
>> I thumbed through the threads on the PG list, and the best summary of the
>> answers you received is:
>>
>> A. Yes you can probably do that, but it would likely be extremely complicated
>> and Django won't necessarily make it easy.
>>
>> B. The "problem" you are trying to solve is more of a "preference" with a
>> questionable motive of speed increases.
>>
>>
>> There wasn't a great amount of support for what you are trying to do, and I
>> doubt you'll find much on this list.
>>
>> The DB should not be responsible for business logic (in this case,
>> authorization rules). DB's are only good at storing, searching, and returning
>> data. Data doesn't care who you are, nor does the DBMS past the table level
>> in most cases.
>>
>> There are several other points to consider. 
>>
>> - By moving this logic in to the DB, you are almost certainly vendor locking
>> yourself to the DB. If your project is not distributed to others, then it may
>> not be an issue. If you do, abstract away the function calls as much as
>> possible to build an internal Python API. If you need to change the
>> underlying database functionality later, your application code should remain
>> relatively untouched, and you can send the bundle of money in labor you saved
>> to me. ;-)
>>
>> - You'll almost certainly take a performance hit when connecting to the
>> database. If each connection to the DB is using a different user, then you
>> likely cannot take advantage of things like DB connection pooling. Every
>> request would require that a connection be built, utilized, and then torn
>> down. Those operations have a cost in both time and resources.
>>
>> - It likely won't scale well. Assuming you have a fair number of unique users
>> with concurrent connections (depending on the resources available and tuning,
>> this could be as little as a few dozen), your DB now has to manage at least a
>> single connection or
>>
>>
>> -- 
>> You received this message because you are subscribed to the Google Groups
>> "Django users" group.
>> To unsubscribe 

Re: Row based permissions: In DB or App? ... farewell pain

[James Schneider]

Sorry for the duplicate, accidently hit send before I was done, finished
below.

On Aug 3, 2017 1:08 AM, "guettli"  wrote:

First I asked a similar question on the postgresql-general list. The
discussion[1] has settled there.

Now I would love the hear what you think.


I am thinking about rewriting an existing application which uses
PostgreSQL via Django.

Up to now the permission checks are done at the application level.

Up to now queries like: "Show all items which the current user is
allowed to modify" result in complicated SQL and
this leads to slow queries.

Up to now there is one db-user and the application does the filtering
of rows to prevent application users to see
items which they are not allowed to see.

I guess most web applications work like this.

I would like to reduce the "ifing and elsing" in my python code (less
conditions, less bugs, more SQL, more performance)
One important intention for me: I would like to avoid the redundancy.
As soon as I want to query for
"Show all items which the current user is allowed to modify" I need
the permission checking in a SQL WHERE condition.

If I implement this. Then my code which might look like this is redundant:

{{{

def has_perm(obj, user):
if user.is_superuser:
return True
...

}}}


Yes, I feel farewell pain. I love Python, but I guess I will use perm
checking via SQL WHERE for new projects in the future.

What do you think?

 Regards,
   Thomas Güttler

[1]: 
https://www.postgresql.org/message-id/e662fd8a-6001-514c-71e8-01718444f338%40thomas-guettler.de

I thumbed through the threads on the PG list, and the best summary of the
answers you received is:

A. Yes you can probably do that, but it would likely be extremely
complicated and Django won't necessarily make it easy.

B. The "problem" you are trying to solve is more of a "preference" with a
questionable motive of speed increases.


There wasn't a great amount of support for what you are trying to do, and I
doubt you'll find much on this list.

The DB should not be responsible for business logic (in this case,
authorization rules). DB's are only good at storing, searching, and
returning data. Data doesn't care who you are, nor does the DBMS past the
table level in most cases.

There are several other points to consider.

- By moving this logic in to the DB, you are almost certainly vendor
locking yourself. If your project is not distributed to others, then it may
not be an issue. If you do, abstract away the function calls as much as
possible to build an internal Python API. If you need to change the
underlying database functionality later, your application code should
remain relatively untouched, and you can send the bundle of money in labor
you saved to me. ;-)

- You'll almost certainly take a performance hit when connecting to the
database. If each connection to the DB is using a different user, then you
likely cannot take advantage of things like DB connection pooling. Every
request would require that a connection be built, utilized, and then torn
down. Those operations have a cost in both time and resources. Under load,
that cost will likely be noticeable.

- It likely won't scale well. Assuming you have a fair number of unique
users with concurrent connections (depending on the resources available and
tuning, this could be as little as a few dozen), your DB now has to manage
at least a single connection per user. DB's may or may not fare well under
those conditions. I haven't tried that model, though, so I may be mistaken.
Managing dozens, hundreds, or thousands of threads/processes in the DB all
attacking the same data set does not sound desirable, especially with
locking and/or transactions in the mix.

- It will likely be very rigid. DB's are not necessarily good at what it is
you are trying to do, and may lack features. Any set of rules you establish
will probably be more basic than you are anticipating/hoping, or will be
near impossible to modify once in production. Again, this is a guess.

- Performance gains may be marginal, especially weighted against the amount
of complexity introduced. Your claim that the DB queries are "slow" is
probably somewhat accurate due to the GFK usage by the contrib.auth
package. However, the GFK's provide a great deal of flexibility, which
usually offsets the marginal performance hit they introduce. I'd rather run
two reasonably fast queries than rely on a custom rolled set of triggers,
DB views, stored procedures, and black magic offered by the DB.

- Maintenance and sync will be a nightmare. Users who are disabled,
modified, or deleted may pose a risk of synch issues, as now you have to
keep that data in sync in two locations (ie the users' password).

Your argument of "if/elif" statements being undesirable for auth is likely
not based on any decent production system, granted they can get very hairy
in complex scenarios. I can chalk that up to personal preference, but I
think it unwise to discard an awesome tool in your chest i

Re: How to handle nested backward lookups in a template for a generic detail view?

[Thomas Hughes]

Just FYI - the issue was with using 'image.url' rather than 
'image.image.url' in code labeled with 'do something with image' in the 
HTML template above.

On Monday, August 7, 2017 at 3:52:15 PM UTC-4, Thomas Hughes wrote:
>
> I have a generic detail view serving content for 'project' to an HTML 
> template with the following code: 
>
> {% for detail in project.projectdetail_set.all %}
> {% for image in detail.projectdetailimage_set.all %}
> do something with image
> {% endfor %}
> {% endfor %}
>
> and my models look like:
>
> class Project(models.Model):
> name = models.CharField(max_length=1000)
> start_date = models.DateField()
> abstract = models.TextField()
> abstract_image = models.ImageField(storage=PROJECT_STORAGE)
>
> def __str__(self):
> return self.name
>
> class ProjectDetail(models.Model):
> project = models.ForeignKey(Project, on_delete=models.CASCADE)
> name = models.CharField(max_length=1000)
> text = models.TextField()
>
> def __str__(self):
> return self.name
>
> class ProjectDetailImage(models.Model):
> detail = models.ForeignKey(ProjectDetail, on_delete=models.CASCADE)
> image = models.ImageField(storage=PROJECT_STORAGE)
>
> It looks like generic detail view only arranges for backward lookup on the 
> 'project' via .projectdetail_set.all but not on the 'detail' as the HTML 
> for .projectdetailimage_set.all just never shows up in the HTML source. I 
> am wondering then what is the proper way to handle nested ForeignKeys like 
> this, basically like a Book > Section > Chapter structure where a Book has 
> several Sections and a Section has several Chapters and Chapters are only 
> associated with Sections and Sections are only associated with Books.
>

-- 
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/aca8ff0e-cf46-407d-9a58-36feb7d76276%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: How to handle nested backward lookups in a template for a generic detail view?

[Александр Христюхин (roboslone)]

Hi,

First of all, you can use `related_name` in your model fields to get pretty 
backref names (so you don't have to use image_set everywhere).

Second, you're missing dots in your template (`for detail in 
project.projectdetail_set.all`).

And finally, your model is called ProjectDetailImage and it has a field, that 
is named `image`. So you won't be able to get rid of `image.image.url`. 
However, you can move your image to ProjectDetail model (add field `image = 
models.ImageField(...)`) and use it like so:

{% for detail in project.projectdetail_set.all %}

{% endfor %}

> On 9 Aug 2017, at 15:33, Thomas Hughes  wrote:
> 
> Just FYI - the issue was with using 'image.url' rather than 'image.image.url' 
> in code labeled with 'do something with image' in the HTML template above.
> 
> On Monday, August 7, 2017 at 3:52:15 PM UTC-4, Thomas Hughes wrote:
> I have a generic detail view serving content for 'project' to an HTML 
> template with the following code: 
> 
> {% for detail in project.projectdetail_set.all %}
> {% for image in detail.projectdetailimage_set.all %}
> do something with image
> {% endfor %}
> {% endfor %}
> and my models look like:
> 
> class Project(models.Model):
> name = models.CharField(max_length=1000)
> start_date = models.DateField()
> abstract = models.TextField()
> abstract_image = models.ImageField(storage=PROJECT_STORAGE)
> 
> def __str__(self):
> return self.name 
> 
> class ProjectDetail(models.Model):
> project = models.ForeignKey(Project, on_delete=models.CASCADE)
> name = models.CharField(max_length=1000)
> text = models.TextField()
> 
> def __str__(self):
> return self.name 
> 
> class ProjectDetailImage(models.Model):
> detail = models.ForeignKey(ProjectDetail, on_delete=models.CASCADE)
> image = models.ImageField(storage=PROJECT_STORAGE)
> It looks like generic detail view only arranges for backward lookup on the 
> 'project' via .projectdetail_set.all but not on the 'detail' as the HTML for 
> .projectdetailimage_set.all just never shows up in the HTML source. I am 
> wondering then what is the proper way to handle nested ForeignKeys like this, 
> basically like a Book > Section > Chapter structure where a Book has several 
> Sections and a Section has several Chapters and Chapters are only associated 
> with Sections and Sections are only associated with Books.
> 
> 
> -- 
> 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/aca8ff0e-cf46-407d-9a58-36feb7d76276%40googlegroups.com
>  
> .
> For more options, visit https://groups.google.com/d/optout 
> .

-- 
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/71ADE1A0-A0A8-435E-8104-9B89931BAA19%40gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: How to handle nested backward lookups in a template for a generic detail view?

[Александр Христюхин (roboslone)]

Whoops, looks like all dots are in place, my mistake. First and last points are 
still valid, though.

> On 9 Aug 2017, at 16:08, Александр Христюхин (roboslone) 
>  wrote:
> 
> Hi,
> 
> First of all, you can use `related_name` in your model fields to get pretty 
> backref names (so you don't have to use image_set everywhere).
> 
> Second, you're missing dots in your template (`for detail in 
> project.projectdetail_set.all`).
> 
> And finally, your model is called ProjectDetailImage and it has a field, that 
> is named `image`. So you won't be able to get rid of `image.image.url`. 
> However, you can move your image to ProjectDetail model (add field `image = 
> models.ImageField(...)`) and use it like so:
> 
> {% for detail in project.projectdetail_set.all %}
> 
> {% endfor %}
> 
>> On 9 Aug 2017, at 15:33, Thomas Hughes > > wrote:
>> 
>> Just FYI - the issue was with using 'image.url' rather than 
>> 'image.image.url' in code labeled with 'do something with image' in the HTML 
>> template above.
>> 
>> On Monday, August 7, 2017 at 3:52:15 PM UTC-4, Thomas Hughes wrote:
>> I have a generic detail view serving content for 'project' to an HTML 
>> template with the following code: 
>> 
>> {% for detail in project.projectdetail_set.all %}
>> {% for image in detail.projectdetailimage_set.all %}
>> do something with image
>> {% endfor %}
>> {% endfor %}
>> and my models look like:
>> 
>> class Project(models.Model):
>> name = models.CharField(max_length=1000)
>> start_date = models.DateField()
>> abstract = models.TextField()
>> abstract_image = models.ImageField(storage=PROJECT_STORAGE)
>> 
>> def __str__(self):
>> return self.name 
>> 
>> class ProjectDetail(models.Model):
>> project = models.ForeignKey(Project, on_delete=models.CASCADE)
>> name = models.CharField(max_length=1000)
>> text = models.TextField()
>> 
>> def __str__(self):
>> return self.name 
>> 
>> class ProjectDetailImage(models.Model):
>> detail = models.ForeignKey(ProjectDetail, on_delete=models.CASCADE)
>> image = models.ImageField(storage=PROJECT_STORAGE)
>> It looks like generic detail view only arranges for backward lookup on the 
>> 'project' via .projectdetail_set.all but not on the 'detail' as the HTML for 
>> .projectdetailimage_set.all just never shows up in the HTML source. I am 
>> wondering then what is the proper way to handle nested ForeignKeys like 
>> this, basically like a Book > Section > Chapter structure where a Book has 
>> several Sections and a Section has several Chapters and Chapters are only 
>> associated with Sections and Sections are only associated with Books.
>> 
>> 
>> -- 
>> 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/aca8ff0e-cf46-407d-9a58-36feb7d76276%40googlegroups.com
>>  
>> .
>> For more options, visit https://groups.google.com/d/optout 
>> .
> 

-- 
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/E9E21E4C-B503-4005-86DA-8FFA5629A85F%40gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Row based permissions: In DB or App? ... farewell pain

[guettli]

Am Montag, 7. August 2017 09:43:00 UTC+2 schrieb Andréas Kühne:
>
> Hi,
>
> I understand your concern, however I would like to learn more about how 
> you intend to solve the problem. The only way I could see a solution would 
> be to change the database user depending on which application user is 
> logged in. That would mean updating users and permissions in the database 
> every time it changes on the application level. I think this would add a 
> lot of complexity that you really don't want. 
>
>
Using the postgres users would be possible, but like you I think this makes 
things more complicated than necessary.


 

> You could of course have one role for each group you intend to have in the 
> application and then apply the permissions accordingly. That would however 
> mean that your user permissions solution is very rigid. One of the things 
> that I like about django is the ability to add and delete permissions 
> easily and swiftly. I'm wondering if you instead couldn't create mixins to 
> make sure that the permissions are correct for each object. That way the 
> code will be easily testable and also less error prone. However it won't 
> create great SQL queries though.
>
> Also - I find that working in Python is a lot easier than working in raw 
> SQL :-) but you will of course need to adapt the queries to make them 
> faster (which can be done by prefetching for example).
>
>
Yes, writing python is more easy, but if you need the conditions in SQL 
WHERE to get a queryset, you don't have python. You have a nice ORM 
MyModel.objects.filter(...) which
is nice and helps to create the needed SQL statements.


 

> That's just my 2 cents.
>
> Regards,
>
> Andréas
>
> 2017-08-07 8:43 GMT+02:00 guettli  >:
>
>> Hello this post is now four days old. I would like to hear from other 
>> people.
>>
>> Something like:
>>
>>  "I have no clue what you are talking about" or 
>>  "I understand your concerns, but I have no clue, too" or
>>  "Thank you about talking about this, this raised my awareness"
>>
>> would make me happy.
>>
>> Thank you.
>>
>> Am Donnerstag, 3. August 2017 10:07:53 UTC+2 schrieb guettli:
>>>
>>> First I asked a similar question on the postgresql-general list. The 
>>> discussion[1] has settled there.
>>>
>>> Now I would love the hear what you think.
>>>
>>>
>>> I am thinking about rewriting an existing application which uses PostgreSQL 
>>> via Django.
>>>
>>> Up to now the permission checks are done at the application level.
>>>
>>> Up to now queries like: "Show all items which the current user is allowed 
>>> to modify" result in complicated SQL and
>>> this leads to slow queries.
>>>
>>> Up to now there is one db-user and the application does the filtering of 
>>> rows to prevent application users to see
>>> items which they are not allowed to see.
>>>
>>> I guess most web applications work like this.
>>>
>>> I would like to reduce the "ifing and elsing" in my python code (less 
>>> conditions, less bugs, more SQL, more performance)
>>> One important intention for me: I would like to avoid the redundancy. As 
>>> soon as I want to query for 
>>> "Show all items which the current user is allowed to modify" I need the 
>>> permission checking in a SQL WHERE condition.
>>>
>>> If I implement this. Then my code which might look like this is redundant:
>>>
>>> {{{
>>>
>>> def has_perm(obj, user):
>>> if user.is_superuser:
>>> return True
>>> ...
>>>
>>> }}}
>>>
>>>
>>> Yes, I feel farewell pain. I love Python, but I guess I will use perm 
>>> checking via SQL WHERE for new projects in the future.
>>>
>>> What do you think?
>>>
>>>  Regards,
>>>Thomas Güttler
>>>
>>> [1]: 
>>> https://www.postgresql.org/message-id/e662fd8a-6001-514c-71e8-01718444f338%40thomas-guettler.de
>>>
>>> -- 
>> 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/b2f0f560-9e83-4a90-9277-23c19f992c0b%40googlegroups.com
>>  
>> 
>> .
>> For more options, visit https://groups.google.com/d/optout.
>>
>
>

-- 
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/17c3c627-6cce

Re: Row based permissions: In DB or App? ... farewell pain

[guettli]

Am Montag, 7. August 2017 09:55:45 UTC+2 schrieb Mike Morris:
>
> I have no expertise in the field, but I've chosen not to let that stop me 
> from making a suggestion :-)
>
> How about splitting the difference:
>
>1. Assign & track permissions on the application side, then 
>2. Pass the permission level/parameters into a Stored Procedure in the 
>database 
>
> If the Stored Procedure accepted permission info, it would not even need 
> to know who the user was, just their permissions. (So no need for DB user 
> switching, etc) ACLs would be enforced 100% in the DB, while rights 
> management stayed in the app.
>
> You'd just have to figure out a flexible enough set or parameters to pass 
> into the stored procedure to allow all the permission permutations you 
> need... ever... ;-)
>
>
Yes, sounds good. Thank you for your feedback.

 

> On 08/07/2017 12:42 AM, Andréas Kühne wrote:
>
> Hi, 
>
> I understand your concern, however I would like to learn more about how 
> you intend to solve the problem. The only way I could see a solution would 
> be to change the database user depending on which application user is 
> logged in. That would mean updating users and permissions in the database 
> every time it changes on the application level. I think this would add a 
> lot of complexity that you really don't want. 
>
> You could of course have one role for each group you intend to have in the 
> application and then apply the permissions accordingly. That would however 
> mean that your user permissions solution is very rigid. One of the things 
> that I like about django is the ability to add and delete permissions 
> easily and swiftly. I'm wondering if you instead couldn't create mixins to 
> make sure that the permissions are correct for each object. That way the 
> code will be easily testable and also less error prone. However it won't 
> create great SQL queries though.
>
> Also - I find that working in Python is a lot easier than working in raw 
> SQL :-) but you will of course need to adapt the queries to make them 
> faster (which can be done by prefetching for example).
>
> That's just my 2 cents.
>
> Regards,
>
> Andréas
>
> 2017-08-07 8:43 GMT+02:00 guettli  >:
>
>> Hello this post is now four days old. I would like to hear from other 
>> people.
>>
>> Something like:
>>
>>  "I have no clue what you are talking about" or 
>>  "I understand your concerns, but I have no clue, too" or
>>  "Thank you about talking about this, this raised my awareness"
>>
>> would make me happy.
>>
>> Thank you.
>>
>> Am Donnerstag, 3. August 2017 10:07:53 UTC+2 schrieb guettli: 
>>>
>>> First I asked a similar question on the postgresql-general list. The 
>>> discussion[1] has settled there.
>>>
>>> Now I would love the hear what you think.
>>>
>>>
>>> I am thinking about rewriting an existing application which uses PostgreSQL 
>>> via Django.
>>>
>>> Up to now the permission checks are done at the application level.
>>>
>>> Up to now queries like: "Show all items which the current user is allowed 
>>> to modify" result in complicated SQL and
>>> this leads to slow queries.
>>>
>>> Up to now there is one db-user and the application does the filtering of 
>>> rows to prevent application users to see
>>> items which they are not allowed to see.
>>>
>>> I guess most web applications work like this.
>>>
>>> I would like to reduce the "ifing and elsing" in my python code (less 
>>> conditions, less bugs, more SQL, more performance)
>>>
>>> One important intention for me: I would like to avoid the redundancy. As 
>>> soon as I want to query for 
>>> "Show all items which the current user is allowed to modify" I need the 
>>> permission checking in a SQL WHERE condition.
>>>
>>> If I implement this. Then my code which might look like this is redundant:
>>>
>>> {{{
>>>
>>> def has_perm(obj, user):
>>> if user.is_superuser:
>>> return True
>>> ...
>>>
>>> }}}
>>>
>>>
>>> Yes, I feel farewell pain. I love Python, but I guess I will use perm 
>>> checking via SQL WHERE for new projects in the future.
>>>
>>> What do you think?
>>>  Regards,
>>>Thomas Güttler
>>>
>>> [1]: 
>>> https://www.postgresql.org/message-id/e662fd8a-6001-514c-71e8-01718444f338%40thomas-guettler.de
>>>
>>> -- 
>> 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/b2f0f560-9e83-4a90-9277-23c19f992c0b%40googlegroups.com
>>  
>> 
>> .
>> For more options, visit https://groups.google.com

Re: Row based permissions: In DB or App? ... farewell pain

[guettli]

Am Montag, 7. August 2017 14:48:54 UTC+2 schrieb Vijay Khemlani:
>
> I use django-guardian for object level permissions and it works 
> surprisingly well
>

Good to hear this. I will have a look at it.
 

>
> On Mon, Aug 7, 2017 at 4:59 AM, Antonis Christofides <
> ant...@djangodeployment.com > wrote:
>
>> Hello,
>>
>> This is a tricky issue and we need to start from the basics. You already 
>> know the basics, but they bear repeating. (Related questions are relatively 
>> common, which is why this is something like the third time I'm pasting this 
>> information here).
>>
>> As you know, RDBMS's keep their own list of users and have sophisticated 
>> permissions systems with which different users have different permissions 
>> on different tables. This is particularly useful in desktop applications 
>> that connect directly to the database. Web applications changed that. 
>> Instead of the RDBMS managing the users and their permissions, we have a 
>> single RDBMS user as which Django connects to the RDBMS, and this user has 
>> full permissions on the database. The actual users and their permissions 
>> are managed by Django itself (more precisely, by the included Django app 
>> django.contrib.auth), using database tables created by Django. What a user 
>> can or cannot do is decided by Django, not by the RDBMS. This is a pity 
>> because django.contrib.auth (or the equivalent in other web frameworks) 
>> largely duplicates functionality that already exists in the RDBMS, and 
>> because having the RDBMS check the permissions is more robust and more 
>> secure. I believe that the reason web frameworks were developed this way is 
>> independence from any specific RDBMS, but I don't really know.
>>
>> So the canonical way of working is to have a single *database user* as 
>> which Django logs on to the database, with full permissions on the database 
>> (including permission to create and delete tables), and many *Django 
>> users*, each one with different permissions. Typically only one Django 
>> superuser is created. I call the superuser "admin", which I believe is the 
>> common practice.
>>
>> You can probably do things differently, and maybe there exist custom 
>> database backends that would allow you to switch the database user on 
>> login, but if there's no compelling reason you should really stick to the 
>> canonical way.
>>
>> So, I agree with you that, in theory, it would be more elegant (and more 
>> robust and more secure) to do this thing at the db level, and that it is a 
>> pity that Django and similar systems have moved this functionality from the 
>> db to the app. However, as I said, without a compelling reason you should 
>> really stick to the canonical way. The canonical way is more maintainable, 
>> because it's widely used. It will be easier for other programmers to 
>> understand what you are doing. Elegance of solution is not compelling 
>> enough. A compelling reason would be, for example, if you also have a 
>> desktop application that is controlled by the user and connects directly to 
>> the database.
>>
>> Regards,
>>
>> Antonis
>>
>> Antonis Christofideshttp://djangodeployment.com
>>
>>
>> On 2017-08-07 09:43, guettli wrote:
>>
>> Hello this post is now four days old. I would like to hear from other 
>> people.
>>
>> Something like:
>>
>>  "I have no clue what you are talking about" or 
>>  "I understand your concerns, but I have no clue, too" or
>>  "Thank you about talking about this, this raised my awareness"
>>
>> would make me happy.
>>
>> Thank you.
>>
>> Am Donnerstag, 3. August 2017 10:07:53 UTC+2 schrieb guettli: 
>>>
>>> First I asked a similar question on the postgresql-general list. The 
>>> discussion[1] has settled there.
>>>
>>> Now I would love the hear what you think.
>>>
>>>
>>> I am thinking about rewriting an existing application which uses PostgreSQL 
>>> via Django.
>>>
>>> Up to now the permission checks are done at the application level.
>>>
>>> Up to now queries like: "Show all items which the current user is allowed 
>>> to modify" result in complicated SQL and
>>> this leads to slow queries.
>>>
>>> Up to now there is one db-user and the application does the filtering of 
>>> rows to prevent application users to see
>>> items which they are not allowed to see.
>>>
>>> I guess most web applications work like this.
>>>
>>> I would like to reduce the "ifing and elsing" in my python code (less 
>>> conditions, less bugs, more SQL, more performance)
>>>
>>> One important intention for me: I would like to avoid the redundancy. As 
>>> soon as I want to query for 
>>> "Show all items which the current user is allowed to modify" I need the 
>>> permission checking in a SQL WHERE condition.
>>>
>>> If I implement this. Then my code which might look like this is redundant:
>>>
>>> {{{
>>>
>>> def has_perm(obj, user):
>>> if user.is_superuser:
>>> return True
>>> ...
>>>
>>> }}}
>>>
>>>
>>> Yes, I feel farewell pain. I love Python, but I gu

Re: Row based permissions: In DB or App? ... farewell pain

[guettli]

Am Mittwoch, 9. August 2017 10:04:25 UTC+2 schrieb James Schneider:
>
>
>
> On Aug 3, 2017 1:08 AM, "guettli" > wrote:
>
> First I asked a similar question on the postgresql-general list. The 
> discussion[1] has settled there.
>
> Now I would love the hear what you think.
>
>
> I am thinking about rewriting an existing application which uses PostgreSQL 
> via Django.
>
> Up to now the permission checks are done at the application level.
>
> Up to now queries like: "Show all items which the current user is allowed to 
> modify" result in complicated SQL and
> this leads to slow queries.
>
> Up to now there is one db-user and the application does the filtering of rows 
> to prevent application users to see
> items which they are not allowed to see.
>
> I guess most web applications work like this.
>
> I would like to reduce the "ifing and elsing" in my python code (less 
> conditions, less bugs, more SQL, more performance)
> One important intention for me: I would like to avoid the redundancy. As soon 
> as I want to query for 
> "Show all items which the current user is allowed to modify" I need the 
> permission checking in a SQL WHERE condition.
>
> If I implement this. Then my code which might look like this is redundant:
>
> {{{
>
> def has_perm(obj, user):
> if user.is_superuser:
> return True
> ...
>
> }}}
>
>
> Yes, I feel farewell pain. I love Python, but I guess I will use perm 
> checking via SQL WHERE for new projects in the future.
>
> What do you think?
>
>  Regards,
>Thomas Güttler
>
> [1]: 
> https://www.postgresql.org/message-id/e662fd8a-6001-514c-71e8-01718444f338%40thomas-guettler.de
>
> I thumbed through the threads on the PG list, and the best summary of the 
> answers you received is:
>
> A. Yes you can probably do that, but it would likely be extremely 
> complicated and Django won't necessarily make it easy.
>
> B. The "problem" you are trying to solve is more of a "preference" with a 
> questionable motive of speed increases.
>
>
> There wasn't a great amount of support for what you are trying to do, and 
> I doubt you'll find much on this list.
>
> The DB should not be responsible for business logic (in this case, 
> authorization rules). DB's are only good at storing, searching, and 
> returning data. Data doesn't care who you are, nor does the DBMS past the 
> table level in most cases.
>
> There are several other points to consider. 
>
> - By moving this logic in to the DB, you are almost certainly vendor 
> locking yourself to the DB. If your project is not distributed to others, 
> then it may not be an issue. If you do, abstract away the function calls as 
> much as possible to build an internal Python API. If you need to change the 
> underlying database functionality later, your application code should 
> remain relatively untouched, and you can send the bundle of money in labor 
> you saved to me. ;-)
>
> - You'll almost certainly take a performance hit when connecting to the 
> database. If each connection to the DB is using a different user, then you 
> likely cannot take advantage of things like DB connection pooling. Every 
> request would require that a connection be built, utilized, and then torn 
> down. Those operations have a cost in both time and resources.
>
> - It likely won't scale well. Assuming you have a fair number of unique 
> users with concurrent connections (depending on the resources available and 
> tuning, this could be as little as a few dozen), your DB now has to manage 
> at least a single connection or
>
>
>
 

My concern is that this python code can't return a queryset with all items 
where a given permission+user tuple match.


def has_perm(obj, user):
if user.is_superuser:
return True

This means I need a SQL WHERE condition

For example MyModel.objects.filter(Q(...)|Q())  

I never wanted business logic in the database. Sorry, if you misunderstood me.


-- 
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/64d929fa-ea5c-49ca-8b9f-5ff872616435%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Row based permissions: In DB or App? ... farewell pain

[guettli]

Am Mittwoch, 9. August 2017 10:46:10 UTC+2 schrieb James Schneider:
>
> Sorry for the duplicate, accidently hit send before I was done, finished 
> below.
>
> On Aug 3, 2017 1:08 AM, "guettli" > wrote:
>
> First I asked a similar question on the postgresql-general list. The 
> discussion[1] has settled there.
>
> Now I would love the hear what you think.
>
>
> I am thinking about rewriting an existing application which uses PostgreSQL 
> via Django.
>
> Up to now the permission checks are done at the application level.
>
> Up to now queries like: "Show all items which the current user is allowed to 
> modify" result in complicated SQL and
> this leads to slow queries.
>
> Up to now there is one db-user and the application does the filtering of rows 
> to prevent application users to see
> items which they are not allowed to see.
>
> I guess most web applications work like this.
>
> I would like to reduce the "ifing and elsing" in my python code (less 
> conditions, less bugs, more SQL, more performance)
> One important intention for me: I would like to avoid the redundancy. As soon 
> as I want to query for 
> "Show all items which the current user is allowed to modify" I need the 
> permission checking in a SQL WHERE condition.
>
> If I implement this. Then my code which might look like this is redundant:
>
> {{{
>
> def has_perm(obj, user):
> if user.is_superuser:
> return True
> ...
>
> }}}
>
>
> Yes, I feel farewell pain. I love Python, but I guess I will use perm 
> checking via SQL WHERE for new projects in the future.
>
> What do you think?
>
>  Regards,
>Thomas Güttler
>
> [1]: 
> https://www.postgresql.org/message-id/e662fd8a-6001-514c-71e8-01718444f338%40thomas-guettler.de
>
> I thumbed through the threads on the PG list, and the best summary of the 
> answers you received is:
>
> A. Yes you can probably do that, but it would likely be extremely 
> complicated and Django won't necessarily make it easy.
>
> B. The "problem" you are trying to solve is more of a "preference" with a 
> questionable motive of speed increases.
>
>
> There wasn't a great amount of support for what you are trying to do, and 
> I doubt you'll find much on this list.
>
> The DB should not be responsible for business logic (in this case, 
> authorization rules). DB's are only good at storing, searching, and 
> returning data. Data doesn't care who you are, nor does the DBMS past the 
> table level in most cases.
>
> There are several other points to consider. 
>
> - By moving this logic in to the DB, you are almost certainly vendor 
> locking yourself. If your project is not distributed to others, then it may 
> not be an issue. If you do, abstract away the function calls as much as 
> possible to build an internal Python API. If you need to change the 
> underlying database functionality later, your application code should 
> remain relatively untouched, and you can send the bundle of money in labor 
> you saved to me. ;-)
>
>

Vendor locking? Yes, that's true. My solution is fixed to PostgreSQL. But 
for me this is not a problem.


- You'll almost certainly take a performance hit when connecting to the 
> database. If each connection to the DB is using a different user, then you 
> likely cannot take advantage of things like DB connection pooling. Every 
> request would require that a connection be built, utilized, and then torn 
> down. Those operations have a cost in both time and resources. Under load, 
> that cost will likely be noticeable.
>
>
I think our servers can handle the load well. Somewhere the permission 
checks need to be done. I think the db is faster than python if there are 
many rows.

 

> - It likely won't scale well. Assuming you have a fair number of unique 
> users with concurrent connections (depending on the resources available and 
> tuning, this could be as little as a few dozen), your DB now has to manage 
> at least a single connection per user. DB's may or may not fare well under 
> those conditions. I haven't tried that model, though, so I may be mistaken. 
> Managing dozens, hundreds, or thousands of threads/processes in the DB all 
> attacking the same data set does not sound desirable, especially with 
> locking and/or transactions in the mix.
>
> - It will likely be very rigid. DB's are not necessarily good at what it 
> is you are trying to do, and may lack features. Any set of rules you 
> establish will probably be more basic than you are anticipating/hoping, or 
> will be near impossible to modify once in production. Again, this is a 
> guess.
>
> - Performance gains may be marginal, especially weighted against the 
> amount of complexity introduced. Your claim that the DB queries are "slow" 
> is probably somewhat accurate due to the GFK usage by the contrib.auth 
> package. However, the GFK's provide a great deal of flexibility, which 
> usually offsets the marginal performance hit they introduce. I'd rather run 
> two reasonably fast queries than rely on a c

Re: How to handle nested backward lookups in a template for a generic detail view?

[Thomas Hughes]

Thank you for your reply.

I understand your third point.  In this application though I have a many 
images to a single detail structure.

For your first point "use `related_name` in your model fields to get pretty 
backref names (so you don't have to use image_set everywhere)", how do I do 
that and maintain the ability to reference the data via the two-fold nested 
loop I need in my HTML template?

Thanks,

Tom

On Wednesday, August 9, 2017 at 9:10:33 AM UTC-4, Александр Христюхин wrote:
>
> Whoops, looks like all dots are in place, my mistake. First and last 
> points are still valid, though.
>
> On 9 Aug 2017, at 16:08, Александр Христюхин (roboslone) <
> robo...@gmail.com > wrote:
>
> Hi,
>
> First of all, you can use `related_name` in your model fields to get 
> pretty backref names (so you don't have to use image_set everywhere).
>
> Second, you're missing dots in your template (`for detail in 
> project.projectdetail_set.all`).
>
> And finally, your model is called ProjectDetailImage and it has a field, 
> that is named `image`. So you won't be able to get rid of 
> `image.image.url`. However, you can move your image to ProjectDetail model 
> (add field `image = models.ImageField(...)`) and use it like so:
>
> {% for detail in project.projectdetail_set.all %}
> 
> {% endfor %}
>
> On 9 Aug 2017, at 15:33, Thomas Hughes  > wrote:
>
> Just FYI - the issue was with using 'image.url' rather than 
> 'image.image.url' in code labeled with 'do something with image' in the 
> HTML template above.
>
> On Monday, August 7, 2017 at 3:52:15 PM UTC-4, Thomas Hughes wrote:
>>
>> I have a generic detail view serving content for 'project' to an HTML 
>> template with the following code: 
>>
>> {% for detail in project.projectdetail_set.all %}
>> {% for image in detail.projectdetailimage_set.all %}
>> do something with image
>> {% endfor %}
>> {% endfor %}
>>
>> and my models look like:
>>
>> class Project(models.Model):
>> name = models.CharField(max_length=1000)
>> start_date = models.DateField()
>> abstract = models.TextField()
>> abstract_image = models.ImageField(storage=PROJECT_STORAGE)
>>
>> def __str__(self):
>> return self.name
>>
>> class ProjectDetail(models.Model):
>> project = models.ForeignKey(Project, on_delete=models.CASCADE)
>> name = models.CharField(max_length=1000)
>> text = models.TextField()
>>
>> def __str__(self):
>> return self.name
>>
>> class ProjectDetailImage(models.Model):
>> detail = models.ForeignKey(ProjectDetail, on_delete=models.CASCADE)
>> image = models.ImageField(storage=PROJECT_STORAGE)
>>
>> It looks like generic detail view only arranges for backward lookup on 
>> the 'project' via .projectdetail_set.all but not on the 'detail' as the 
>> HTML for .projectdetailimage_set.all just never shows up in the HTML 
>> source. I am wondering then what is the proper way to handle nested 
>> ForeignKeys like this, basically like a Book > Section > Chapter structure 
>> where a Book has several Sections and a Section has several Chapters and 
>> Chapters are only associated with Sections and Sections are only associated 
>> with Books.
>>
>
> -- 
> 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/aca8ff0e-cf46-407d-9a58-36feb7d76276%40googlegroups.com
>  
> 
> .
> For more options, visit https://groups.google.com/d/optout.
>
>
>
>

-- 
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/ae732c74-1ab9-4176-9a6f-8fbebff37fc8%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Row based permissions: In DB or App? ... farewell pain

[Vijay Khemlani]

https://django-guardian.readthedocs.io/en/stable/userguide/check.html#get-objects-for-user

projects = get_objects_for_user(request.user, 'projects.view_project')


On Wed, Aug 9, 2017 at 10:55 AM, guettli 
wrote:

>
>
> Am Mittwoch, 9. August 2017 10:04:25 UTC+2 schrieb James Schneider:
>
>>
>>
>> On Aug 3, 2017 1:08 AM, "guettli"  wrote:
>>
>> First I asked a similar question on the postgresql-general list. The 
>> discussion[1] has settled there.
>>
>> Now I would love the hear what you think.
>>
>>
>> I am thinking about rewriting an existing application which uses PostgreSQL 
>> via Django.
>>
>> Up to now the permission checks are done at the application level.
>>
>> Up to now queries like: "Show all items which the current user is allowed to 
>> modify" result in complicated SQL and
>> this leads to slow queries.
>>
>> Up to now there is one db-user and the application does the filtering of 
>> rows to prevent application users to see
>> items which they are not allowed to see.
>>
>> I guess most web applications work like this.
>>
>> I would like to reduce the "ifing and elsing" in my python code (less 
>> conditions, less bugs, more SQL, more performance)
>> One important intention for me: I would like to avoid the redundancy. As 
>> soon as I want to query for
>> "Show all items which the current user is allowed to modify" I need the 
>> permission checking in a SQL WHERE condition.
>>
>> If I implement this. Then my code which might look like this is redundant:
>>
>> {{{
>>
>> def has_perm(obj, user):
>> if user.is_superuser:
>> return True
>> ...
>>
>> }}}
>>
>>
>> Yes, I feel farewell pain. I love Python, but I guess I will use perm 
>> checking via SQL WHERE for new projects in the future.
>>
>> What do you think?
>>
>>  Regards,
>>Thomas Güttler
>>
>> [1]: 
>> https://www.postgresql.org/message-id/e662fd8a-6001-514c-71e8-01718444f338%40thomas-guettler.de
>>
>> I thumbed through the threads on the PG list, and the best summary of the
>> answers you received is:
>>
>> A. Yes you can probably do that, but it would likely be extremely
>> complicated and Django won't necessarily make it easy.
>>
>> B. The "problem" you are trying to solve is more of a "preference" with a
>> questionable motive of speed increases.
>>
>>
>> There wasn't a great amount of support for what you are trying to do, and
>> I doubt you'll find much on this list.
>>
>> The DB should not be responsible for business logic (in this case,
>> authorization rules). DB's are only good at storing, searching, and
>> returning data. Data doesn't care who you are, nor does the DBMS past the
>> table level in most cases.
>>
>> There are several other points to consider.
>>
>> - By moving this logic in to the DB, you are almost certainly vendor
>> locking yourself to the DB. If your project is not distributed to others,
>> then it may not be an issue. If you do, abstract away the function calls as
>> much as possible to build an internal Python API. If you need to change the
>> underlying database functionality later, your application code should
>> remain relatively untouched, and you can send the bundle of money in labor
>> you saved to me. ;-)
>>
>> - You'll almost certainly take a performance hit when connecting to the
>> database. If each connection to the DB is using a different user, then you
>> likely cannot take advantage of things like DB connection pooling. Every
>> request would require that a connection be built, utilized, and then torn
>> down. Those operations have a cost in both time and resources.
>>
>> - It likely won't scale well. Assuming you have a fair number of unique
>> users with concurrent connections (depending on the resources available and
>> tuning, this could be as little as a few dozen), your DB now has to manage
>> at least a single connection or
>>
>>
>>
>
>
> My concern is that this python code can't return a queryset with all items
> where a given permission+user tuple match.
>
>
> def has_perm(obj, user):
> if user.is_superuser:
> return True
>
> This means I need a SQL WHERE condition
>
> For example MyModel.objects.filter(Q(...)|Q())
>
> I never wanted business logic in the database. Sorry, if you misunderstood me.
>
>
> --
> 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/64d929fa-ea5c-49ca-8b9f-5ff872616435%40googlegroups.com
> 
> .
>
> For more options, visit https://groups.google.com/d/optout.
>

-- 
You received this m

How to Minify, obfuscate, and compress django code

[hin Account]

Hi All,

I am developing one products using the django framework.  I don't to share 
the my source code with the client. I just want to share the obfuscated 
code with client. Please tell me how to do the same in django? 

-- 
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/2228c7ab-6e2b-4492-a2a7-84d8a59bbeb9%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Deploy Django on Apache server

[Akshay Jagirdar]

Hi Guys,

Please help me with deployment of Django project on Apache server. 

My System environment...

OS   : Fedora 20
Python : 2.7
Django : 1.11
Apache: 2.4

What I know is i have modify httpd.conf file in /etc/httpd/conf/httpd.conf, 
please help me with this.

Thanks,
Akshay Jagirdar

-- 
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/3fe6114f-f184-4827-b93d-caffcb01fc47%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Deploy Django on Apache server

[Andréas Kühne]

2017-08-09 9:01 GMT+02:00 Akshay Jagirdar :

> Hi Guys,
>
> Please help me with deployment of Django project on Apache server.
>
> My System environment...
>
> OS   : Fedora 20
> Python : 2.7
> Django : 1.11
> Apache: 2.4
>
> What I know is i have modify httpd.conf file in
> /etc/httpd/conf/httpd.conf, please help me with this.
>
> Thanks,
> Akshay Jagirdar
>
> --
> 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/3fe6114f-f184-4827-b93d-caffcb01fc47%40googlegroups.com
> 
> .
> For more options, visit https://groups.google.com/d/optout.
>

Hi,

Check out:
https://docs.djangoproject.com/en/1.11/howto/deployment/wsgi/modwsgi/

or:
https://www.digitalocean.com/community/tutorials/how-to-serve-django-applications-with-apache-and-mod_wsgi-on-centos-7

Not specifically for Fedora 20 - but rather good howto.

Regards,

Andréas

-- 
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/CAK4qSCf4ytL8EOTYMbkWESZGswDkD-B-3gNZtgxJds7yZkZRQw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Channels vs Django-websocket-redis

[John Byrne]

Thanks for the reply. I didn't realize that ws4redis doesn't have the 
concepts of consumers and routing. That's something I'll have to look into 
further. The documentation for ws4redis isn't great so that makes it 
harder. 

On Saturday, August 5, 2017 at 9:19:24 AM UTC-4, Artem Malyshev wrote:
>
> Hi,
>
> I look at django-websockets-redis really quickly. If you decide to use 
> Redis ASGI layer it may look familiar.
>
> Main differences I notice so far:
>
> - ws4redis doesn't have concept of consumers and routing
> - it's coupled to the subset of WebSocket usage
> - it's propagate redis to the library api
>
> On another hand Django Channels 
>
> - can be used with different channels layers (redis, rabbitmq, ipc, 
> inmemory)
> - have clean api based on consumers and routing
> - can handle more than just websockets. HTTP2 and HTTP1.1 are supported. 
> Chat protocols like slack or irc are possible.
> - you can trigger consumers from other consumers, without talking to 
> websocket.
>
> On Friday, August 4, 2017 at 1:09:44 PM UTC+3, John Byrne wrote:
>>
>> I'm trying to evaluate these two Websockets solutions for Django. Has 
>> anyone here done compared these?
>>
>> I don't fully understand what the differences between them are. I think 
>> the main difference is that Channels can generalize all requests (websocket 
>> or request/response) to be handled by channel consumers, but if that's the 
>> case, then:
>>
>> 1. I think you only get that if you have all your traffic come through 
>> ASGI (Daphne), right? If you route WSGI traffic and Websockets traffic 
>> separately, then wouldn't you really have something similar to the solution 
>> described here: 
>> http://django-websocket-redis.readthedocs.io/en/latest/running.html#django-with-websockets-for-redis-behind-nginx-using-uwsgi.
>>  
>> Or is there still some big difference between that solution and Channels?
>>
>> 2. If #1 above is the main difference, I don't fully understand what the 
>> advantage(s) of this are. Is the ASGI-only mode required in order to have 
>> the websockets code and the wsgi code share the Django session? 
>>
>> Thanks!
>>
>

-- 
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/44769a05-2bf9-4c6a-96ee-96d8af4d74ee%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: How to handle nested backward lookups in a template for a generic detail view?

[Александр Христюхин (roboslone)]

You still can reference the data:


class Foo(models.Model):
pass

class Bar(models.Model):
foo = models.ForeignKey(Foo, related_name='bars')

f = Foo()
b1 = Bar(foo=f)
b2 = Bar(foo=f)

f.bars.all()  # 


> On 9 Aug 2017, at 18:19, Thomas Hughes  wrote:
> 
> Thank you for your reply.
> 
> I understand your third point.  In this application though I have a many 
> images to a single detail structure.
> 
> For your first point "use `related_name` in your model fields to get pretty 
> backref names (so you don't have to use image_set everywhere)", how do I do 
> that and maintain the ability to reference the data via the two-fold nested 
> loop I need in my HTML template?
> 
> Thanks,
> 
> Tom
> 
> On Wednesday, August 9, 2017 at 9:10:33 AM UTC-4, Александр Христюхин wrote:
> Whoops, looks like all dots are in place, my mistake. First and last points 
> are still valid, though.
> 
>> On 9 Aug 2017, at 16:08, Александр Христюхин (roboslone) > > wrote:
>> 
>> Hi,
>> 
>> First of all, you can use `related_name` in your model fields to get pretty 
>> backref names (so you don't have to use image_set everywhere).
>> 
>> Second, you're missing dots in your template (`for detail in 
>> project.projectdetail_set.all`).
>> 
>> And finally, your model is called ProjectDetailImage and it has a field, 
>> that is named `image`. So you won't be able to get rid of `image.image.url`. 
>> However, you can move your image to ProjectDetail model (add field `image = 
>> models.ImageField(...)`) and use it like so:
>> 
>> {% for detail in project.projectdetail_set.all %}
>> 
>> {% endfor %}
>> 
>>> On 9 Aug 2017, at 15:33, Thomas Hughes >> > wrote:
>>> 
>>> Just FYI - the issue was with using 'image.url' rather than 
>>> 'image.image.url' in code labeled with 'do something with image' in the 
>>> HTML template above.
>>> 
>>> On Monday, August 7, 2017 at 3:52:15 PM UTC-4, Thomas Hughes wrote:
>>> I have a generic detail view serving content for 'project' to an HTML 
>>> template with the following code: 
>>> 
>>> {% for detail in project.projectdetail_set.all %}
>>> {% for image in detail.projectdetailimage_set.all %}
>>> do something with image
>>> {% endfor %}
>>> {% endfor %}
>>> and my models look like:
>>> 
>>> class Project(models.Model):
>>> name = models.CharField(max_length=1000)
>>> start_date = models.DateField()
>>> abstract = models.TextField()
>>> abstract_image = models.ImageField(storage=PROJECT_STORAGE)
>>> 
>>> def __str__(self):
>>> return self.name 
>>> 
>>> class ProjectDetail(models.Model):
>>> project = models.ForeignKey(Project, on_delete=models.CASCADE)
>>> name = models.CharField(max_length=1000)
>>> text = models.TextField()
>>> 
>>> def __str__(self):
>>> return self.name 
>>> 
>>> class ProjectDetailImage(models.Model):
>>> detail = models.ForeignKey(ProjectDetail, on_delete=models.CASCADE)
>>> image = models.ImageField(storage=PROJECT_STORAGE)
>>> It looks like generic detail view only arranges for backward lookup on the 
>>> 'project' via .projectdetail_set.all but not on the 'detail' as the HTML 
>>> for .projectdetailimage_set.all just never shows up in the HTML source. I 
>>> am wondering then what is the proper way to handle nested ForeignKeys like 
>>> this, basically like a Book > Section > Chapter structure where a Book has 
>>> several Sections and a Section has several Chapters and Chapters are only 
>>> associated with Sections and Sections are only associated with Books.
>>> 
>>> 
>>> -- 
>>> 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/aca8ff0e-cf46-407d-9a58-36feb7d76276%40googlegroups.com
>>>  
>>> .
>>> For more options, visit https://groups.google.com/d/optout 
>>> .
>> 
> 
> 
> -- 
> 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 th

Error rendering template ==> raise KeyError (key) KeyError: 'address_inline'

[Elias Coutinho]

Good afternoon people,

I'm trying to render a template with django-material
I am getting the error message in the template as below:






And the complete traceback is as follows:


traceback 



I am submitting below the project template:


*forms.py*


from django import forms
from django.forms import ModelForm, Field
from material import Fieldset, Layout, Row, Span6

from danibraz.persons.models import Client, Author, Book, Employee



class ClientsForm(forms.ModelForm):
name = forms.CharField(label='Nome', required=True)
birthday = forms.DateField(label='Nascimento', required=False)
address1 = forms.CharField(label='Endereço completo')
purchase_limit = forms.DecimalField(label='Limite de compra')
compra_sempre = forms.BooleanField(label='Compra sempre?', required=False)

class Meta:
model = Client
fields = '__all__'

layout = Layout(
Fieldset("Inclua um cliente",
 Row('name', ),
 Row('birthday','purchase_limit'),
 Row('address1', ),
 Row('compra_sempre', ),
 )
)


*models.py*


# from django.contrib.auth.models import User
from django.db import models


class Person(models.Model):
name = models.CharField('Nome',max_length=100)
birthday = models.DateField('Aniversário')
address1 = models.CharField('Endereço 1',max_length=100)
purchase_limit = models.DecimalField('Limite de compra',max_digits=15, 
decimal_places=2)


class Meta:
verbose_name_plural = 'pessoas'
verbose_name = 'pessoa'

def __str__(self):
return self.name


class Address(models.Model):
KINDS = (
('P', 'PRINCIPAL'),
('C', 'COBRANÇA'),
('E', 'ENTREGA'),
)
person = models.ForeignKey('Person')
kynd = models.CharField('Tipo', max_length=1, choices=KINDS)
public_place = models.CharField('Logradouro',max_length=150)
number = models.CharField('Número',max_length=150)
city = models.CharField('Cidade',max_length=150)
state = models.CharField('Estado',max_length=150)
zipcode = models.CharField('Cep',max_length=10)
country = models.CharField('País',max_length=150)
phone = models.CharField('Fone',max_length=50)

class Meta:
verbose_name_plural = 'endereços'
verbose_name = 'endereço'

def __str__(self):
return self.public_place


*urls.py*


from django.conf.urls import url, include
from django.views.i18n import JavaScriptCatalog

from danibraz.persons import views
from danibraz.persons.views import clients, employees, NewProfissoesPessoaView, 
manage_books

urlpatterns = [
url(r'^pessoa/', 
views.NewCadastroPessoaView.as_view(template_name="persons/person_and_professions.html")),

url(r'^jsi18n/$', JavaScriptCatalog.as_view(), name='javascript-catalog'),
url(r'^i18n/', include('django.conf.urls.i18n')),
]


*views.py*


class AddressInline(extra_views.InlineFormSet):
model = Address #Model Address
# Desnecessário
#fields = ['kynd', 'public_place', 'number', 'city', 'state', 'zipcode', 
'country', 'phone', 'delete'] #Campos do endereço

#Desnecessário
# layout = Layout(
# # Campos do Persons
# Row('qualificacao', 'campo_novo_um'),
# Row('campo_novo_dois', 'campo_novo_tres'),
#
# )
# extra = 3# Define aquantidade de linhas a apresentar.
can_delete = True


#LoginRequiredMixin faz a mesma função de @login_required(login_url=LOGIN_URL). 
a ndiferença que LoginRequiredMixin não precisa apontar na url
class NewCadastroPessoaView(LayoutMixin,
  extra_views.NamedFormsetsMixin,
  extra_views.CreateWithInlinesView):
title = "Nova Pessoa"

model = Person# model Person

layout = Layout(
# Campos do Persons
Fieldset("Inclua uma pessoa",
 Row('name', ),
 Row('birthday','purchase_limit'),
 Row('address1', ),
 ),
#Inline dos endereços
Inline('Endereços', AddressInline,),

)

#print('Chegou na linha 340')

def forms_valid(self, form, inlines):
self.object = form.save(commit=False)
#self.object.pessoa_id = self.request.user.id
self.object.save()
return super(NewCadastroPessoaView, self).forms_valid(form, inlines)

def get_success_url(self):
return self.object.get_absolute_url()



Maybe I'm sinning to know something in this code, can anyone help me?

The code is in the github 

I have already asked for help on several discussion lists and could not get 
help.
Anyone have a clue about what I'm doin

[Solved] Re: database tables are not being created

[jjanderson52000]

Andreas,

Thank you for the help. It turned out my __init__.py file was missing in my 
migration directories. Once added, everything ran great.

Jim

On Monday, August 7, 2017 at 3:33:18 PM UTC-4, jjander...@gmail.com wrote:
>
>
> I have been working on a django application for several months, learning 
> as I go. I have run into a problem now and I'm not sure what I should be 
> doing next.
>
> Up until now my admin has worked, but I had a problem and a colleague told 
> me he was pretty sure it was a pycharm bug. He suggested that I remove the 
> database (db.sqlite3). I did that and I also removed all of the existing 
> migration files in my development area.
>
> When I run 'python manage.py makemigrations', I now get the followoing 
> output:
>
> /home/jja/.virtualenvs/PivotalBase-2017.6.16/bin/python 
> /home/jja/prog/newSiggy/manage.py makemigrations
> setting.py: BASE_DIR =  /home/jja/prog/newSiggy
> FINISHED settings.py
> No changes detected
>
> Process finished with exit code 0
>
> Then I run 'python manage.py migrate' and my output is:
>
> /home/jja/.virtualenvs/PivotalBase-2017.6.16/bin/python 
> /home/jja/prog/newSiggy/manage.py migrate
> setting.py: BASE_DIR =  /home/jja/prog/newSiggy
> FINISHED settings.py
> Operations to perform:
>   Apply all migrations: admin, auth, contenttypes, sessions, sites
> Running migrations:
>   No migrations to apply.
>
> Process finished with exit code 0
>
>
> I'm not sure what to do next. My models are in place, my 2 admin 
> directories are in place. I have created an 'xxx_admin' file for each model 
> and I have registered the admin classes. After running 'makemigrations' and 
> 'migrate', a db.sqlite3 file exists, but only the django tables are to be 
> found, not the tables for my models. I'm going through the documentation to 
> try to figure out if I have missed a step in the process, but so far I have 
> not found anything.
>
> Any suggestions?
>
> Jim A.
>

-- 
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/858429c8-d792-46b7-936d-c08b18d58185%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: How to Minify, obfuscate, and compress django code

[Mike Dewhirst]

Have a look in __py cache__

Connected by Motorola

hin Account  wrote:

>Hi All,
>
>I am developing one products using the django framework.  I don't to share the 
>my source code with the client. I just want to share the obfuscated code with 
>client. Please tell me how to do the same in django? 
>
>
>-- 
>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/2228c7ab-6e2b-4492-a2a7-84d8a59bbeb9%40googlegroups.com.
>For more options, visit https://groups.google.com/d/optout.

-- 
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/eneoixa9g7igustijg7liswd.1502325041815%40email.android.com.
For more options, visit https://groups.google.com/d/optout.

Re: How to Minify, obfuscate, and compress django code

[Bernd Wechner]

I'm a little confused as to what this has to do with Django, which runs 
server side. The code it emits to the client is limited to what you put in 
your templates, including perhaps the widgets that django provides for 
forms.

I use a lot of javascript in my forms, and it's my responsibility to minify 
that and include links to the minified code in my templates in production 
(and unminified in development) but these are all django unrelated build 
issues. And solving them depends on django unrelated tool sets you're using.

-- 
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/6a306671-399e-40bc-bee0-cf5837d7c5f6%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Re: Migration of auth.user to custom user

[Mike Dewhirst]

On 7/08/2017 11:55 PM, Tim Graham wrote:

Some steps are outlined in https://code.djangoproject.com/ticket/25313.


OK thanks Tim. I'll start the planning. I'll presume Django 1.10 isn't 
sufficiently different from 1.8 for which the instructions are written.


I wish I wasn't an underconfident wuss!



On Friday, August 4, 2017 at 3:37:08 AM UTC-4, Mike Dewhirst wrote:

I have read  widely (including the docs) and been daunted by the
notion
of coverting auth.user  into a custom user. I have data and wonder if
there have been any recent recipes for doing this?

Thanks

Mike

--
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/c29496a8-1294-481a-8316-5c288b0af6f9%40googlegroups.com 
.

For more options, visit https://groups.google.com/d/optout.



--

Climate Pty Ltd
PO Box 308
Mount Eliza
Vic 3930
Australia +61

T: 03 9034 3977
M: 0411 704 143


--
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/3bade296-ace2-d356-d1bf-d5aa3c25b201%40dewhirst.com.au.
For more options, visit https://groups.google.com/d/optout.