Re: Canonical way of handling multiple types of users? (Profiles vs subclassing django.contrib.auth.models.AbstractUser)

[Melvyn Sopacua]

Hi,

> What is the current canonical way to handle multiple user-profiles in
> Django?

it highly depends on how you see these objects:

1. different types of users (requirement: a user can only be one type)
2. one type of user with additional information from different sources
3. different types of users, but users can be multiple types

Obviously the third is the hardest.

 
On Tuesday 08 November 2016 16:54:43 Victor Hooi wrote:

> For example - say you have "Teachers", "Students", "Parents" - you may
> have slightly different fields for each one and/or different
> behaviour. Students will have things like grades, Parents may have
> 1-to-many Students etc.

Here you clearly think of them as types, instead of Humans and yet they 
can fulfill multiple roles. It also doesn't matter what is in the 
profile, as long as you don't care about enforcing required information 
at the model layer.
You can make one profile model with the union of all fields and use 
group membership to enforce requirements. So a Human which is member of 
the Teachers group must have "date_employed" filled in while Student 
must have "date_enrolled". Similarly, you can use group membership to 
determine what information to show.
Splitting them out in different profiles is a matter of preference and 
optimization, not of design.

> The docs mention using a django.db.models.signals.post_save
>  signals.post_save> signal on User, but I'm guessing that won't work
> here if you have multiple types of users.

When you have multiple *profiles* this will work just fine. It's also 
not a big problem to solve, because user creation and updating is not an 
uncontrollable process like the docs suggest.
User creation via commandline or automated process really only happens 
in tests and backup restore procedures.

In production it's your job to properly set permissions for meddling 
with users in the admin and to provide forms that include relevant 
profile information. When providing good forms the signal is actually 
disruptive: you already have the information available, you save the 
user then save the profile information. Having a signal fire that 
doesn't have access to that profile information is not very useful and 
can lead to validation errors simply because the handler doesn't have 
the context.

> Or are you better off subclassing
> django.contrib.auth.models.AbstractUser? (I get the impression using
> profile models is less invasive).

The case for subclassing is really only one:
Do you not have the right information in the standard user model to 
authenticate the user?
Highly specialized cases aside, it's better to use profiles.

A prominent example for not having the right information is when 
authentication happens with SSL certificates rather then 
username/password. Another is having different authentication servers 
and what server to use is depending on a field that isn't in the user 
model, like "faculty" or "signup_date.year".

Hope this helps,
-- 
Melvyn Sopacua

-- 
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/1678108.SszHfPmntC%40devstation.
For more options, visit https://groups.google.com/d/optout.

Re: Admin - saveasnew to another database

[Melvyn Sopacua]

On Wednesday 09 November 2016 13:59:35 Mike Dewhirst wrote:
> On 9/11/2016 9:13 AM, Tim Graham wrote:
> > Interesting idea. I'd be interested to here more about the use case.
> 
> Simple. I permitted my users to "play" on the staging site and now one
> of them wants to transfer their work to the production site.

Your approach is wrong. You think of this as one django project and 
trying to cheat under the hood, while in fact they are two different 
projects. And by design, staging is not always structually identical to 
production.

Your best approach is to use serialization with natural keys and a job 
scheduler. Cron will do, but there's plenty other schemes allowing you 
to provide feedback about the job queue and expected time of completion.
-- 
Melvyn Sopacua

-- 
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/1646548.Z956crW7yG%40devstation.
For more options, visit https://groups.google.com/d/optout.

Re: Admin - saveasnew to another database

[Tim Graham]

I see. Although I would be interested to see what you come up with, my 
initial reaction is that we wouldn't accept a patch for Django to do this. 
It seems too complex and brittle.

I agree with Melvyn that it seems unusual to use Django's multi-database 
facilities to transfer data between staging and production. 

On Wednesday, November 9, 2016 at 4:51:39 AM UTC-5, Melvyn Sopacua wrote:
>
> On Wednesday 09 November 2016 13:59:35 Mike Dewhirst wrote: 
> > On 9/11/2016 9:13 AM, Tim Graham wrote: 
> > > Interesting idea. I'd be interested to here more about the use case. 
> > 
> > Simple. I permitted my users to "play" on the staging site and now one 
> > of them wants to transfer their work to the production site. 
>
> Your approach is wrong. You think of this as one django project and 
> trying to cheat under the hood, while in fact they are two different 
> projects. And by design, staging is not always structually identical to 
> production. 
>
> Your best approach is to use serialization with natural keys and a job 
> scheduler. Cron will do, but there's plenty other schemes allowing you 
> to provide feedback about the job queue and expected time of completion. 
> -- 
> Melvyn Sopacua 
>

-- 
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/ccfa9aef-d1c3-45e0-a894-c07a2701c1aa%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: strategies for adding a custom group permission

[Melvyn Sopacua]

On Tuesday 08 November 2016 09:55:51 Larry Martell wrote:

> I need to add a configurable data filter that will be used in my app
> and I want that filter to be specifiable at the django group level. I
> want to be able to give users permission, both at the group level and
> the user level, to edit this filter. But I want that permission to be
> separate and distinct from the general change group permission.
> 
> Anyone have a method to do this?

By design, you cannot relax permissions. You can grant and re-deny 
though or re-implement how change permission is determined. Wether you 
can determine "I should grant Change permission, even though the group 
doesn't have it, because the request is for editing the filter *only*" 
is tricky.

To grant change permission and then override it later, use the "user 
passes test" mechanism:


-- 
Melvyn Sopacua

-- 
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/1940858.ZoTOQO7cGd%40devstation.
For more options, visit https://groups.google.com/d/optout.

Re: Best practices for directories in which to store stuff in production

[Vijay Khemlani]

I prefer to keep everything in /home (at least the virtualenv, project
code, settings and logs), that way you don't need special permissions to
modify those files and it is more or less separated from the system files.

static and media files in Amazon S3

Caching... I used memcached, so I have no experience with using files in
that regard

On Wed, Nov 9, 2016 at 4:56 AM, ludovic coues  wrote:

> If I had to use such scheme, I would put the django application in a
> package for the target system. Like a .deb file for exemple.
> If your primary way of deploying is a git push from test/QA to production,
> split directory will cause plenty of headaches.
>
> Also, with an installation like this, I wouldn't use a virtualenv. By
> using /usr/local/lib, you are making your application a part of the system.
> It's like if a standard application was using a non-standard library. I
> wouldn't expect that.
>
> But that's my 2 cents
>
> 2016-11-09 8:36 GMT+01:00 Antonis Christofides <
> anto...@djangodeployment.com>:
>
>> Hello,
>>
>> I was thinking about using this scheme:
>> /usr/local/lib/projectname
>> Program files (i.e. repository)
>> /usr/local/lib/projectname-virtualenv
>> Virtualenv
>> /var/lib/projectname/media
>> Media files
>> /var/cache/projectname/static
>> Static files, collected with collectstatic
>> /var/cache/projectname/cache
>> File-based cache
>> /var/log/projectname
>> Log files
>> /etc/projectname
>> Configuration (mostly settings.py)
>>
>> I was wondering whether people could find it counter-intuitive, or
>> whether there could be trouble training new recruits. I understand that
>> some people are using /opt or /srv or /home, and that it may be common
>> practice to put the virtualenv, static, and media files inside the
>> repository working directory.
>>
>> My backup script automatically excludes /usr and /var/cache from backup,
>> so I can decide what shall be backed up just by placing it in the
>> appropriate directory. This is the main reason I put static files and
>> file-based cache in /var/cache, and why I dislike schemes where program
>> files and data are put in a single directory such as /srv/projectname.
>> So how does the above look to you, and what other practices have you seen?
>>
>> (I'm asking primarily because I'm writing a book on Django deployment and
>> I'm wondering what best practice to propose to the reader.)
>>
>> Thanks!
>>
>> --
>> Antonis Christofideshttp://djangodeployment.com  
>>
>> --
>> 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/ms
>> gid/django-users/cc2851e9-89cc-3a87-aac6-b0532e5b2233%40djan
>> godeployment.com
>> 
>> .
>> For more options, visit https://groups.google.com/d/optout.
>>
>
>
>
> --
>
> Cordialement, Coues Ludovic
> +336 148 743 42
>
> --
> 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/CAEuG%2BTaU-BDeOAXf3iTVk7cLfMdwKSRV1GikFTT
> q4QxQW1xuPw%40mail.gmail.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/CALn3ei0QWQvnG%2BsDdxK--S4cpdTi5RPnM8DstAxDxAoO9nspOg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: strategies for adding a custom group permission

[Larry Martell]

On Wed, Nov 9, 2016 at 8:32 AM, Melvyn Sopacua  wrote:
> On Tuesday 08 November 2016 09:55:51 Larry Martell wrote:
>
>> I need to add a configurable data filter that will be used in my app
>> and I want that filter to be specifiable at the django group level. I
>> want to be able to give users permission, both at the group level and
>> the user level, to edit this filter. But I want that permission to be
>> separate and distinct from the general change group permission.
>>
>> Anyone have a method to do this?
>
> By design, you cannot relax permissions. You can grant and re-deny
> though or re-implement how change permission is determined. Wether you
> can determine "I should grant Change permission, even though the group
> doesn't have it, because the request is for editing the filter *only*"
> is tricky.
>
> To grant change permission and then override it later, use the "user
> passes test" mechanism:
> 

I was able to do this by adding a custom admin index page, change_form
and some javascript.

-- 
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/CACwCsY5b1vd_KMYE7gQayzXtCWVh8dOfCfnizLLszp-4AcCrbg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Setting up jQuery in debian with virtualenv

[Gary Roach]

Hi all,

I am just starting to use jQuery and Ajax in my project and am having 
trouble setting things up.


I am using Eclipse + pyDev as an IDE. This setup stores everything in a 
workspace directory in my home directory. Instead of putting the whole 
project inside a virtualenv wrapper, things work better if the venv is 
external to the actual project files and the venv contents referenced in 
the Eclipse setup. In that venv file (djenv) there is the following:



/home/gary/workspace/djenv/lib/python3.5/site-packages/django/contrib/admin/static/admin/js/vendor/jquery/jquery.min.js



Now to the setup of my main html page. According to W3schools.com I 
should include one of the following in the html head section:



 




 or


 
https://ajax.googleapis.com/ajax/libs/jquery/3.1.1/jquery.min.js";>



Neither of these fit my situation. I don't have a separate 
jquery-3.1.1.min.js file and don't want to use the google source.


What I wish to know is can I use something like:
> 
> "djenv/lib/python3.5/site-packages/django/contrib/admin/static/admin/js/vendor/jquery/jquery.min.js"

>

or can I use just