Lack of View permission in Django

[Ankit Agrawal]

I have an active Django project where the admin panel is used by the 
customer support team. I have two questions -

1. Django lacks a `view` permission because of which I have to assign the 
change permission to the customer support team which is slightly dangerous. 
I have some models for which the customer support team needs just the view 
access and not the change access because of security issues. Any workaround 
to this?

2. Although the admin panel can be used as a CRM, are there any popular CRM 
django apps than can be used instead of the admin panel?

-- 
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 http://groups.google.com/group/django-users.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-users/6ac40e1a-d3e7-492f-9589-388ee95978db%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Django REST Framework : Serializer field level validation of OneToOne fields

[Ankit Agrawal]

The code corresponding to my query is rather big hence I posted it on Stack 
Overflow - 
http://stackoverflow.com/questions/32063427/django-rest-framework-serializer-field-level-validation-of-onetoone-fields

-- 
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 http://groups.google.com/group/django-users.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-users/5fbb50b5-d3ca-4356-8f5a-7d979d4852ba%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Different auth user models withoout doing multi-table inheritance

[Ankit Agrawal]

On Tuesday, August 11, 2015 at 2:31:11 AM UTC+5:30, James Schneider wrote:
>
> On Mon, Aug 10, 2015 at 12:11 PM, Ankit Agrawal <g...@gmail.com 
> > wrote:
>
>> Hi James,
>>
>>  Correct me if I am wrong but if I understood you correctly, I should 
>> be able to implement it this way -
>>
>> class User(AbstractBaseUser, PermissionsMixin):
>> common_fields_go_her = ...
>>
>> objects = CustomUserManager()
>> class Meta:
>> abstract = True
>>
>>
>> class Customer(User):
>> customer_specific_fields = ...
>>
>>
>> class Merchant(User):
>> merchant_speicifc_fields = ...
>>
>>
>
> Yes this is exactly what I was thinking. You were asking about avoiding 
> MTI, and this is how you would do it. 
>
>  
>
>> In this case, what would be AUTH_USER_MODEL? If i am not wrong, an 
>> abstract base class cannot be an AUTH_USER_MODEL.
>>
>>
> Ah, now we get back in to Carl's original answer and why having a single 
> (probably custom) user class with a separate profile table makes sense. 
> Obviously you can't point AUTH_USER_MODEL at the abstract class, leaving 
> you with a choice about whether you want Customer's or Merchant's to be the 
> target of AUTH_USER_MODEL. Not ideal either way. It was unclear to me 
> whether or not you were going to use the default auth backends to log both 
> types of users in, or if those were simply storage models, with the actual 
> users who log in to the system in a separate model (which is where 
> AUTH_USER_MODEL would be pointing).
>
> You could have a single CustomUser class that has a static choices=((1, 
> 'Customer'),(2,'Merchant')) for a particular field so that a DB hit is not 
> involved whenever the user is pulled to make the determination as to the 
> type of user. Not very flexible, but cheap to process.
>
> If you are planning on having a ton of fields added to your CustomUser 
> class, I would highly recommend you take the DB hit and create a separate 
> set of related models to a single CustomUser (similar to the profile idea 
> that Carl mentioned). That way you aren't returning a ton of data for every 
> single request, which can get expensive in the long run, even with only 
> using a single query. 
>
> # models.py
> class CustomUser(AbstractBaseUser, PermissionsMixin):
> # small number of fields needed for almost every single request
> # should rarely change structure via migrations
>
> class CustomerData(models.Model):
> # OneToOne back to CustomerUser
> # Other fields that are not necessarily needed for every request, 
> loaded on demand
> # may be often modified by migrations
>
> class MerchantData(models.Model):
> # OneToOne back to CustomerUser
> # Other fields that are not necessarily needed for every request, 
> loaded on demand
> # may be often modified by migrations
>
> # settings.py
> AUTH_USER_MODEL = 'myapp.models.CustomUser'
>
>
> Note that you'll want your AUTH_USER_MODEL to change as little as possible 
> in production. Errors in that model will often have a far-reaching effect. 
> The two Data models will likely change more often, and will probably have 
> less of an impact in the event of an issue with a migration.
>
> As Carl mentioned the 2Scoops authors were not saying that OneToOne 
> relationships were bad and to never use them, they just don't like the 
> 'implied' OneToOne relationships Django creates when MTI is used. OneToOne 
> fields are not something that should be made scary, rather, they should 
> simply be made explicit in the code.
>

Hi James, thanks for the elaborate answer. Not that explicit OneToOne 
relationships are bad but I was just trying to avoid the overhead due to 
the JOINs that comes with it.

> -James
>
>

-- 
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 http://groups.google.com/group/django-users.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-users/3bb8808a-07cd-40c3-b740-a4adb535716b%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Different auth user models withoout doing multi-table inheritance

[Ankit Agrawal]

Hi James,

 Correct me if I am wrong but if I understood you correctly, I should 
be able to implement it this way -

class User(AbstractBaseUser, PermissionsMixin):
common_fields_go_her = ...

objects = CustomUserManager()
class Meta:
abstract = True


class Customer(User):
customer_specific_fields = ...


class Merchant(User):
merchant_speicifc_fields = ...

In this case, what would be AUTH_USER_MODEL? If i am not wrong, an abstract 
base class cannot be an AUTH_USER_MODEL.


On Monday, August 10, 2015 at 11:20:43 PM UTC+5:30, James Schneider wrote:

> That is an incorrect assumption. Abstract model classes do not generate 
> any database tables, and are specifically designed for inheritance purposes 
> (otherwise they are pretty much useless). It is impossible for a OneToOne 
> field to exist that points to an abstract class.
>
>
> https://docs.djangoproject.com/en/1.8/topics/db/models/#abstract-base-classes
>
> If you need a similar example, look at how Django defines its own User 
> class:
>
>
> https://github.com/django/django/blob/1.8.3/django/contrib/auth/models.py#L436
>
> User inherits from AbstractUser (abstract class that adds 
> username/password fields, etc.), which in turn inherits from 
> AbstractBaseUser (abstract class that adds other methods for grabbing 
> various attributes of a User object). There are no excessive joins created 
> by queries against the User class because both AbstractUser and 
> AbstractBaseUser are both...abstract. They don't exist in the DB. 
>
> -James
>
> On Mon, Aug 10, 2015 at 10:29 AM, Ankit Agrawal <g...@gmail.com 
> > wrote:
>
>> @James: Even if I implement a Custom abstract class inheriting from 
>> AbstractBaseUser, the Custom Abstract Class would have a explicit 
>> OneToOneField to the AbstractBaseUser, which essentially would mean having 
>> overheads due to JOINs as in MTI.
>>
>>
>> Ankit Agrawal,
>> IIT Bombay.
>>
>> On Mon, Aug 10, 2015 at 10:17 PM, James Schneider <jrschn...@gmail.com 
>> > wrote:
>>
>>> If you want to avoid MT inheritance, look at inheriting from 
>>> AbstractBaseUser using a custom abstract class where you can add your extra 
>>> custom fields. Your two types of users (inheriting from your new abstract 
>>> class) would then be standard, separate models.
>>>
>>> -James
>>> On Aug 10, 2015 9:24 AM, "Robin Lery" <robi...@gmail.com > 
>>> wrote:
>>>
>>>> You surely can use Choice field for either Customer or Merchant in your 
>>>> custom user class.
>>>> On 10 Aug 2015 20:12, "Avraham Serour" <tov...@gmail.com > 
>>>> wrote:
>>>>
>>>>> I personally like a profile model, but if you implement two you may 
>>>>> have headaches when doing a reverse relation from user, you would need to 
>>>>> check every time of the request.user is a customer or merchant.
>>>>>
>>>>> In any case what is the difference between them anyway? Why can't a 
>>>>> user be both?
>>>>>
>>>>> On Mon, Aug 10, 2015, 4:38 PM Ankit Agrawal <g...@gmail.com 
>>>>> > wrote:
>>>>>
>>>>>> I am working on a project which has two different sets of users - 
>>>>>> Customer and Merchant. Both of these users should be able to 
>>>>>> register and login to their respective profiles. The most obvious choice 
>>>>>> to 
>>>>>> implement this that came to my mind was to make two different models 
>>>>>> Customer and Merchant that inherit from a BaseUser model that will 
>>>>>> store the common fields i.e. Multi-table inheritance - 
>>>>>> https://docs.djangoproject.com/en/1.8/topics/db/models/#multi-table-inheritance
>>>>>>
>>>>>>
>>>>>> Quoting Two Scoops of Django -
>>>>>>
>>>>>>
>>>>>> At all costs, everyone should avoid multi-table inheritance (see warning 
>>>>>> above) since it adds both confusion and substantial overhead...Adds 
>>>>>> substantial overhead since each query on a child table requires joins 
>>>>>> with all parent tables.
>>>>>>
>>>>>> I would like to know if and why having an explicit OneToOneField is 
>>>>>> better than Multi-table inheritance. Also, are there any other better 
>>>>>> ways 
>>>>>> to model the above relationship?
>>>>&g

Re: Different auth user models withoout doing multi-table inheritance

[Ankit Agrawal]

@James: Even if I implement a Custom abstract class inheriting from
AbstractBaseUser, the Custom Abstract Class would have a explicit
OneToOneField to the AbstractBaseUser, which essentially would mean having
overheads due to JOINs as in MTI.


Ankit Agrawal,
IIT Bombay.

On Mon, Aug 10, 2015 at 10:17 PM, James Schneider <jrschneide...@gmail.com>
wrote:

> If you want to avoid MT inheritance, look at inheriting from
> AbstractBaseUser using a custom abstract class where you can add your extra
> custom fields. Your two types of users (inheriting from your new abstract
> class) would then be standard, separate models.
>
> -James
> On Aug 10, 2015 9:24 AM, "Robin Lery" <robinl...@gmail.com> wrote:
>
>> You surely can use Choice field for either Customer or Merchant in your
>> custom user class.
>> On 10 Aug 2015 20:12, "Avraham Serour" <tovm...@gmail.com> wrote:
>>
>>> I personally like a profile model, but if you implement two you may have
>>> headaches when doing a reverse relation from user, you would need to check
>>> every time of the request.user is a customer or merchant.
>>>
>>> In any case what is the difference between them anyway? Why can't a user
>>> be both?
>>>
>>> On Mon, Aug 10, 2015, 4:38 PM Ankit Agrawal <gra...@gmail.com>
>>> wrote:
>>>
>>>> I am working on a project which has two different sets of users -
>>>> Customer and Merchant. Both of these users should be able to register
>>>> and login to their respective profiles. The most obvious choice to
>>>> implement this that came to my mind was to make two different models
>>>> Customer and Merchant that inherit from a BaseUser model that will
>>>> store the common fields i.e. Multi-table inheritance -
>>>> https://docs.djangoproject.com/en/1.8/topics/db/models/#multi-table-inheritance
>>>>
>>>>
>>>> Quoting Two Scoops of Django -
>>>>
>>>>
>>>> At all costs, everyone should avoid multi-table inheritance (see warning 
>>>> above) since it adds both confusion and substantial overhead...Adds 
>>>> substantial overhead since each query on a child table requires joins with 
>>>> all parent tables.
>>>>
>>>> I would like to know if and why having an explicit OneToOneField is
>>>> better than Multi-table inheritance. Also, are there any other better ways
>>>> to model the above relationship?
>>>>
>>>> --
>>>> 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 http://groups.google.com/group/django-users.
>>>> To view this discussion on the web visit
>>>> https://groups.google.com/d/msgid/django-users/81954b62-2c89-404f-94a5-5f9a485c28c8%40googlegroups.com
>>>> <https://groups.google.com/d/msgid/django-users/81954b62-2c89-404f-94a5-5f9a485c28c8%40googlegroups.com?utm_medium=email_source=footer>
>>>> .
>>>> 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 http://groups.google.com/group/django-users.
>>> To view this discussion on the web visit
>>> https://groups.google.com/d/msgid/django-users/CAFWa6tJar_3PcyOytTsY1EKhbW4Y7M45Kqnt4oU3VLyvGjfrEw%40mail.gmail.com
>>> <https://groups.google.com/d/msgid/django-users/CAFWa6tJar_3PcyOytTsY1EKhbW4Y7M45Kqnt4oU3VLyvGjfrEw%40mail.gmail.com?utm_medium=email_source=footer>
>>> .
>>> 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 http://groups.google.com/g

Different auth user models withoout doing multi-table inheritance

[Ankit Agrawal]

 

I am working on a project which has two different sets of users - Customer 
and Merchant. Both of these users should be able to register and login to 
their respective profiles. The most obvious choice to implement this that 
came to my mind was to make two different models Customer and Merchant that 
inherit from a BaseUser model that will store the common fields i.e. 
Multi-table inheritance - 
https://docs.djangoproject.com/en/1.8/topics/db/models/#multi-table-inheritance


Quoting Two Scoops of Django -


At all costs, everyone should avoid multi-table inheritance (see warning above) 
since it adds both confusion and substantial overhead...Adds substantial 
overhead since each query on a child table requires joins with all parent 
tables.

I would like to know if and why having an explicit OneToOneField is better 
than Multi-table inheritance. Also, are there any other better ways to 
model the above relationship?

-- 
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 http://groups.google.com/group/django-users.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-users/81954b62-2c89-404f-94a5-5f9a485c28c8%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Django SECRET_KEY : Copying hashed passwords into different Django project

[Ankit Agrawal]

 

Hi everyone,


  I have a Django powered site(Project-1) running with some users 
registered on it. I am now creating a revamped version of the site in a new 
separate Django project(Project-2) which I would make live once finished. I 
would need to populate the User data along with their hashed passwords 
currently in database of Project-1 into database of Project-2. Would having 
different SECRET_KEYs for Project-1 and Project-2 be an issue to get the 
hashed passwords migrated and working in Project-2?

-- 
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 http://groups.google.com/group/django-users.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-users/ae4f48e9-08b8-482a-909d-f9cd965b02be%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Django Model field : Ordered List of Foreign Keys

[Ankit Agrawal]

I have a `Route` model which should store an ordered list of stops along 
that route. How should I go about modeling this relation?

class Stop(models.Model):
name = ..
latitude = ..
longitude = ..

class Route(models.Model):
stops_list = # Ordered list of stops on the route


-- 
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 http://groups.google.com/group/django-users.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-users/72e84a42-a0ad-4dcb-bfcd-948d1050c8e2%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Django : DRF Token based Authentication VS JSON Web Token

[Ankit Agrawal]

 
   
Hi everyone,


I am building a real world application where users will access the app 
primarily from Android, iOS devices as well as Desktops.

>From my elementary research, I have realized that token based 
authentication mechanism is more better and elegant for client-server 
models as compared to session based authentication.


In Django, I have found two popular ways to do this -

   1. 
   
http://www.django-rest-framework.org/api-guide/authentication/#tokenauthentication
   2. http://getblimp.github.io/django-rest-framework-jwt/

>From what I understood, option 2] is an extension of 1] except that the 
Token is in the form of JSON(serialized). I would like to understand what 
other differences there are between option 1] and 2] and the 
advantages/disadvantages of choosing either.

-- 
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 http://groups.google.com/group/django-users.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-users/11204a7d-a582-40bd-a9ba-e06abe23afff%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Django JQuery AJAX submit form POST request refreshes the page

[Ankit Agrawal]

Hi everyone,

 I have a login form for which I want the client to send AJAX POST 
request as below with error handling. In case of validation/authentication 
errors, I don't the page to be reloaded or refreshed to the url 
corresponding to POST request Handler(/users/login/) with the JSON string 
received from login view's response. I tried using event.preventDefault() 
as suggested by many answer on SO but could not make it work. Any clue as 
to what is going wrong here? I don't think this to be a Django issue. I 
know that the onsubmit is triggerred because the window redirects to the 
POST handler URL /users/login/ with the expected JSON string response(i.e. 
JsonResponse) - {"error": ["Entered mobile number is not registered"]}

   Please check this stackoverflow link 

 
for the code and complete details. 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 http://groups.google.com/group/django-users.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-users/4b5520d2-d057-4f48-a5fe-52d2c2503b66%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Django admin does not show value of datetime field till seconds/miliseconds

[Ankit Agrawal]

Hi everyone,
   I have a model which has a datetime field. In the django admin, the 
value is shown only till minutes. How can it be configured to display the 
value in second/milisecond?




-- 
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 http://groups.google.com/group/django-users.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-users/e5e6a71c-a5ee-43c8-9ae5-f4a8e673%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.