Converting Speedy Net to Python/Django

[Uri Even-Chen]

To Django Users,

I want to convert my open source social network, Speedy Net
, from PHP to Python and Django. Which Django
packages do you recommend using? I prefer to start with Python 3. I saw the
list of apps on https://www.djangopackages.com/grids/g/social/ , and I
found that django-allauth is the most popular app that supports Python 3.
Do you recommend using it? I think I will change the authentication
functions, to preserve backwards compatibility with Speedy Net - to let
current users log in with their current password, which is saved
hashed/encrypted on the database (with salt). I also want users to be able
to edit their profile, create groups and pages, like pages, join groups and
send messages to each other. I'm also thinking about creating an optional
matching/dating service for Speedy Net users. Which apps/platforms do you
recommend me to use?

Thanks,
Uri.

*Uri Even-Chen*   [image: photo] Phone: +972-54-3995700
Email: u...@speedy.net
Website: http://www.speedysoftware.com/uri/en/
  
    
> Speedypedia in Hebrew and English


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

Re: CSRF cookie not set issue

[Kevin Anyanwu]

base_1.html



  


goals







  
  



Cirriculmn
Notes
Collaborte



  




  


On Thu, Sep 10, 2015 at 8:49 AM, monoBOT  wrote:

> show us the base_1.html
>
> 2015-09-10 16:18 GMT+01:00 :
>
>> By the way, I am using Django 1.8.3 (final)
>>
>>
>> On Thursday, September 10, 2015 at 8:16:11 AM UTC-7, kany...@fonality.com
>> wrote:
>>>
>>> First of all I have done my research and found no reasonable explanation
>>> for my issue. I have a site on heroku that works fine on the first page,
>>> but when I click a button that I have programmed to go to another page, I
>>> obtain the infamous CSRF error. The reason for this error is CSRF cookie is
>>> not set. Here is a description of the background work done on the dev side:
>>>
>>> 1. Settings.py
>>>
>>> MIDDLEWARE_CLASSES = (
>>> 'django.contrib.sessions.middleware.SessionMiddleware',
>>> 'django.middleware.common.CommonMiddleware',
>>> 'django.middleware.csrf.CsrfViewMiddleware',
>>> 'django.contrib.auth.middleware.AuthenticationMiddleware',
>>> 'django.contrib.auth.middleware.SessionAuthenticationMiddleware',
>>> 'django.contrib.messages.middleware.MessageMiddleware',
>>> 'django.middleware.clickjacking.XFrameOptionsMiddleware',
>>> #'django.middleware.security.SecurityMiddleware',
>>>  'django.middleware.csrf.CsrfViewMiddleware',
>>> )
>>>
>>> 2. base.py
>>>
>>> 
>>> {% csrf_token %}
>>>
>>> 
>>> 
>>> 
>>> 
>>> 
>>>   >> placeholder="Password" type="text">
>>> 
>>> 
>>> 
>>>
>>> Log In
>>>
>>> 
>>>
>>>   
>>>
>>> 3. views.py
>>>
>>> def menu(request):
>>>
>>> return render_to_response('home/base_1.html', context_instance =
>>> RequestContext(request, {}) )
>>>
>>> 4. javascript for the function logIn() that is executed when the button
>>> is clicked from (2)
>>>
>>>
>>> function logIn ()
>>> {
>>> alert('Form has been submitted');
>>> document.getElementById('loginform').submit();
>>> }
>>>
>>> I am seriously bewildered and cannot understand why the base_1.html site
>>> is not being rendered and I am getting this CSRF error ! Please help 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 http://groups.google.com/group/django-users.
>> To view this discussion on the web visit
>> https://groups.google.com/d/msgid/django-users/14ec3bc1-c7ff-4d3e-8065-9eae959720fc%40googlegroups.com
>> 
>> .
>>
>> For more options, visit https://groups.google.com/d/optout.
>>
>
>
>
> --
> *monoBOT*
> Visite mi sitio(Visit my site): monobotsoft.es/blog/
>
> --
> You received this message because you are subscribed to a topic in the
> Google Groups "Django users" group.
> To unsubscribe from this topic, visit
> https://groups.google.com/d/topic/django-users/scpBffl8s3A/unsubscribe.
> To unsubscribe from this group and all its topics, 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/CA%2BxOsGCqOXSCs7dFDTNNfgEgKHk2vsbXNEmFN4LpkgNabgjVNA%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 http://groups.google.com/group/django-users.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-users/CAE1x1E1GHk135fGwxVG8e6Gk6EqD51Jv_JsEexE-7r0HuPhkTA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: ATOMIC_REQUESTS setting not working

[EJ]

Small update: Wrapping the view function with *@transaction.atomic* fixes 
the issue -- the queries execute in a transaction as expected.

So I guess my immediate problem is resolved.

If anyone has an idea, I'd still love to know why the view is ignoring the 
top-level TRANSACTION_ATOMIC setting.   In case it's happening elsewhere 
that I'm not aware of.

-- 
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/984cd123-8d50-4c08-ad65-94b7a0a43fd4%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

ATOMIC_REQUESTS setting not working

[EJ]

Hi All,

I have ATOMIC_REQUESTS set to True in my database configuration:

DATABASES = {
'default': {
'ENGINE': 'django.db.backends.postgresql_psycopg2',
'NAME': 'abcd',
'USER': 'user',
'PASSWORD': '',
'HOST': '',
'PORT': '',
'ATOMIC_REQUESTS': True,
}
}


But I started getting the following error when attempting to use 
*select_for_update()* in one particular view:

select_for_update cannot be used outside of a transaction.


As the error suggests, it turns out that database queries inside this 
particular view are not executing inside a transaction, even though 
ATOMIC_REQUESTS is set to True.  I tested this essentially by performing an 
insert within the same view and then throwing an exception -- the change 
was indeed committed.  

I'm not sure why this is occurring.   Other views in my application respect 
the ATOMIC_REQUESTS setting, and I'm able to use select_for_update() 
successfully elsewhere.  There is nothing special about this particular 
view that I can see.  It's just processing a form and inserting some 
records.  I can paste the view code if it helps, but there is really 
nothing remarkable about it, which leads me to believe that the problem 
lies elsewhere.

I have no idea how to debug this.  I would like all requests in my 
application to be wrapped in transactions, as indicated by the 
ATOMIC_REQUESTS setting.  Any help is appreciated.

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/aebf9844-d7e1-4961-bc35-a01b05aba4bf%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Adding dynamic methods to ModelAdmin fails in 1.8

[Simon Charette]

Hi Malcolm,

> With the patch to check an instance rather than a class, perhaps I should 
extend the checks to check the result of get_readonly_fields() rather than 
just obj.readonly_fields. What do you think?

I think the checks should be run statically against ModelAdmin instances, 
that is only the properties of the instances should be checked and not the 
return value of methods that could depend on request properties such as the 
user.

Simon

Le jeudi 10 septembre 2015 13:32:32 UTC-4, Malcolm Box a écrit :
>
> Hi Simon,
>
> On Thursday, 10 September 2015 16:57:51 UTC+1, Simon Charette wrote:
>>
>> Hi Malcolm,
>>
>> > The system check checks that all the values returned from 
>> get_readonly_fields exist as class attributes on the ModelAdmin (or are 
>> callable/fields on model, neither of which helps here). With them being 
>> created via __getattr__, they don't.
>>
>> There might be something else going on here but I highly doubt checks are 
>> ran against the get_readonly_fields() return value since it's a method 
>> bound to a ModelAdmin instance and requires a `request` argument to be 
>> called in the first place.
>>
>>
> My mistake, you're entirely correct. The SystemChecks check the 
> readonly_fields property, not the result of calling get_readonly_fields().
>
> With the patch to check an instance rather than a class, perhaps I should 
> extend the checks to check the result of get_readonly_fields() rather than 
> just obj.readonly_fields. What do you think?
>
> Malcolm
>
> Simon
>>
>> Le jeudi 10 septembre 2015 06:27:13 UTC-4, Malcolm Box a écrit :
>>>
>>> Hi Simon,
>>>
>>> I've tried that, and it still fails the same system check.
>>>
>>> The system check checks that all the values returned from 
>>> get_readonly_fields exist as class attributes on the ModelAdmin (or are 
>>> callable/fields on model, neither of which helps here). With them being 
>>> created via __getattr__, they don't.
>>>
>>> I'm coming to the conclusion that the right behaviour is to run the 
>>> system check against an instance, not the class, since that's what the core 
>>> admin code uses.
>>>
>>> Thanks for the offer to review changes - I'll try to put a patch 
>>> together this week.
>>>
>>> Cheers,
>>>
>>> Malcolm
>>>
>>> On 9 September 2015 at 18:17, Simon Charette  wrote:
>>>
 Hi Malcom,

 What I meant to suggest is to remove the fields from 
 `fields`/`readonly_fields` and dynamically return them in the 
 `get_(fields|readonly_fields)` fields method.

 e.g.

 class ThumbnailFieldsAdmin(models.ModelAdmin):
 fields = []
 readonly_fields = []
 thumbnail_fields = []

 def __getattr__(self, name):
 if name.endswith('_thumbnail'):
 return thumbnail_function
 raise AttributeError

 def get_fields(request, obj=None):
 fields = super(ThumbnailFieldsAdmin, self).get_fields(request, 
 obj=obj)
 return self.thumbnail_fields + fields

 def get_readonly_fields(request, obj=None):
 readonly_fields = super(ThumbnailFieldsAdmin, self).get_fields(
 request, obj=obj)
 return readonly_fields + thumbnail_fields

 But I'm afraid that you'll have to rely on metaclass programming if you 
 want the order of fields to be maintained somehow.

 > I therefore suspect that the check is actually borked, and it should 
 be checking hasattr(instance, field_name) rather than hasattr(cls, 
 field_name)

 The thing is checks are run against ModelAdmin classes and not the 
 instances bound to the site they were registered to 
 .
  
 You could submit a feature request to actually run the test against the 
 instances but since this is really and edge case you'd have to provide a 
 patch/PR if you don't want the ticket to rot in Trac make it to Django 1.9 
 which should enter feature freeze soon enough. I'd be glad to review your 
 proposed changes if you're interested.

 Simon


 Le mercredi 9 septembre 2015 10:31:12 UTC-4, Malcolm Box a écrit :

> Hi Simon,
>
> Thanks for the pointer, but I don't think that helps.
>
> The fields are already declared using the existing fields / 
> readonly_fields attributes on the ExampleAdmin class - and this is what 
> get_fields / get_readonly_fields return. The system check fails because 
> the 
> fields declared don't exist on the ExampleAdmin class nor on the model. 
> Here's the relevant lines from contrib/admin/checks.py:
>
> def _check_readonly_fields_item(self, cls, model, field_name, 
> label):
> if callable(field_name):
> return []
> elif hasattr(cls, field_name):
> return []

Re: Adding dynamic methods to ModelAdmin fails in 1.8

[Malcolm Box]

Hi Simon,

On Thursday, 10 September 2015 16:57:51 UTC+1, Simon Charette wrote:
>
> Hi Malcolm,
>
> > The system check checks that all the values returned from 
> get_readonly_fields exist as class attributes on the ModelAdmin (or are 
> callable/fields on model, neither of which helps here). With them being 
> created via __getattr__, they don't.
>
> There might be something else going on here but I highly doubt checks are 
> ran against the get_readonly_fields() return value since it's a method 
> bound to a ModelAdmin instance and requires a `request` argument to be 
> called in the first place.
>
>
My mistake, you're entirely correct. The SystemChecks check the 
readonly_fields property, not the result of calling get_readonly_fields().

With the patch to check an instance rather than a class, perhaps I should 
extend the checks to check the result of get_readonly_fields() rather than 
just obj.readonly_fields. What do you think?

Malcolm

Simon
>
> Le jeudi 10 septembre 2015 06:27:13 UTC-4, Malcolm Box a écrit :
>>
>> Hi Simon,
>>
>> I've tried that, and it still fails the same system check.
>>
>> The system check checks that all the values returned from 
>> get_readonly_fields exist as class attributes on the ModelAdmin (or are 
>> callable/fields on model, neither of which helps here). With them being 
>> created via __getattr__, they don't.
>>
>> I'm coming to the conclusion that the right behaviour is to run the 
>> system check against an instance, not the class, since that's what the core 
>> admin code uses.
>>
>> Thanks for the offer to review changes - I'll try to put a patch together 
>> this week.
>>
>> Cheers,
>>
>> Malcolm
>>
>> On 9 September 2015 at 18:17, Simon Charette  wrote:
>>
>>> Hi Malcom,
>>>
>>> What I meant to suggest is to remove the fields from 
>>> `fields`/`readonly_fields` and dynamically return them in the 
>>> `get_(fields|readonly_fields)` fields method.
>>>
>>> e.g.
>>>
>>> class ThumbnailFieldsAdmin(models.ModelAdmin):
>>> fields = []
>>> readonly_fields = []
>>> thumbnail_fields = []
>>>
>>> def __getattr__(self, name):
>>> if name.endswith('_thumbnail'):
>>> return thumbnail_function
>>> raise AttributeError
>>>
>>> def get_fields(request, obj=None):
>>> fields = super(ThumbnailFieldsAdmin, self).get_fields(request, 
>>> obj=obj)
>>> return self.thumbnail_fields + fields
>>>
>>> def get_readonly_fields(request, obj=None):
>>> readonly_fields = super(ThumbnailFieldsAdmin, self).get_fields(
>>> request, obj=obj)
>>> return readonly_fields + thumbnail_fields
>>>
>>> But I'm afraid that you'll have to rely on metaclass programming if you 
>>> want the order of fields to be maintained somehow.
>>>
>>> > I therefore suspect that the check is actually borked, and it should 
>>> be checking hasattr(instance, field_name) rather than hasattr(cls, 
>>> field_name)
>>>
>>> The thing is checks are run against ModelAdmin classes and not the 
>>> instances bound to the site they were registered to 
>>> .
>>>  
>>> You could submit a feature request to actually run the test against the 
>>> instances but since this is really and edge case you'd have to provide a 
>>> patch/PR if you don't want the ticket to rot in Trac make it to Django 1.9 
>>> which should enter feature freeze soon enough. I'd be glad to review your 
>>> proposed changes if you're interested.
>>>
>>> Simon
>>>
>>>
>>> Le mercredi 9 septembre 2015 10:31:12 UTC-4, Malcolm Box a écrit :
>>>
 Hi Simon,

 Thanks for the pointer, but I don't think that helps.

 The fields are already declared using the existing fields / 
 readonly_fields attributes on the ExampleAdmin class - and this is what 
 get_fields / get_readonly_fields return. The system check fails because 
 the 
 fields declared don't exist on the ExampleAdmin class nor on the model. 
 Here's the relevant lines from contrib/admin/checks.py:

 def _check_readonly_fields_item(self, cls, model, field_name, 
 label):
 if callable(field_name):
 return []
 elif hasattr(cls, field_name):
 return []
 elif hasattr(model, field_name):
 return []
 else:
 try:
 model._meta.get_field(field_name)
 except FieldDoesNotExist:
 return [
 checks.Error(
 "The value of '%s' is not a callable, an 
 attribute of '%s', or an attribute of '%s.%s'." % (
 label, cls.__name__, model._meta.app_label, 
 model._meta.object_name
 ),
 hint=None,
 obj=cls,

Re: Adding dynamic methods to ModelAdmin fails in 1.8

[Simon Charette]

Hi Malcolm,

> The system check checks that all the values returned from 
get_readonly_fields exist as class attributes on the ModelAdmin (or are 
callable/fields on model, neither of which helps here). With them being 
created via __getattr__, they don't.

There might be something else going on here but I highly doubt checks are 
ran against the get_readonly_fields() return value since it's a method 
bound to a ModelAdmin instance and requires a `request` argument to be 
called in the first place.

Simon

Le jeudi 10 septembre 2015 06:27:13 UTC-4, Malcolm Box a écrit :
>
> Hi Simon,
>
> I've tried that, and it still fails the same system check.
>
> The system check checks that all the values returned from 
> get_readonly_fields exist as class attributes on the ModelAdmin (or are 
> callable/fields on model, neither of which helps here). With them being 
> created via __getattr__, they don't.
>
> I'm coming to the conclusion that the right behaviour is to run the system 
> check against an instance, not the class, since that's what the core admin 
> code uses.
>
> Thanks for the offer to review changes - I'll try to put a patch together 
> this week.
>
> Cheers,
>
> Malcolm
>
> On 9 September 2015 at 18:17, Simon Charette  > wrote:
>
>> Hi Malcom,
>>
>> What I meant to suggest is to remove the fields from 
>> `fields`/`readonly_fields` and dynamically return them in the 
>> `get_(fields|readonly_fields)` fields method.
>>
>> e.g.
>>
>> class ThumbnailFieldsAdmin(models.ModelAdmin):
>> fields = []
>> readonly_fields = []
>> thumbnail_fields = []
>>
>> def __getattr__(self, name):
>> if name.endswith('_thumbnail'):
>> return thumbnail_function
>> raise AttributeError
>>
>> def get_fields(request, obj=None):
>> fields = super(ThumbnailFieldsAdmin, self).get_fields(request, 
>> obj=obj)
>> return self.thumbnail_fields + fields
>>
>> def get_readonly_fields(request, obj=None):
>> readonly_fields = super(ThumbnailFieldsAdmin, self).get_fields(
>> request, obj=obj)
>> return readonly_fields + thumbnail_fields
>>
>> But I'm afraid that you'll have to rely on metaclass programming if you 
>> want the order of fields to be maintained somehow.
>>
>> > I therefore suspect that the check is actually borked, and it should be 
>> checking hasattr(instance, field_name) rather than hasattr(cls, field_name)
>>
>> The thing is checks are run against ModelAdmin classes and not the 
>> instances bound to the site they were registered to 
>> .
>>  
>> You could submit a feature request to actually run the test against the 
>> instances but since this is really and edge case you'd have to provide a 
>> patch/PR if you don't want the ticket to rot in Trac make it to Django 1.9 
>> which should enter feature freeze soon enough. I'd be glad to review your 
>> proposed changes if you're interested.
>>
>> Simon
>>
>>
>> Le mercredi 9 septembre 2015 10:31:12 UTC-4, Malcolm Box a écrit :
>>
>>> Hi Simon,
>>>
>>> Thanks for the pointer, but I don't think that helps.
>>>
>>> The fields are already declared using the existing fields / 
>>> readonly_fields attributes on the ExampleAdmin class - and this is what 
>>> get_fields / get_readonly_fields return. The system check fails because the 
>>> fields declared don't exist on the ExampleAdmin class nor on the model. 
>>> Here's the relevant lines from contrib/admin/checks.py:
>>>
>>> def _check_readonly_fields_item(self, cls, model, field_name, label):
>>> if callable(field_name):
>>> return []
>>> elif hasattr(cls, field_name):
>>> return []
>>> elif hasattr(model, field_name):
>>> return []
>>> else:
>>> try:
>>> model._meta.get_field(field_name)
>>> except FieldDoesNotExist:
>>> return [
>>> checks.Error(
>>> "The value of '%s' is not a callable, an 
>>> attribute of '%s', or an attribute of '%s.%s'." % (
>>> label, cls.__name__, model._meta.app_label, 
>>> model._meta.object_name
>>> ),
>>> hint=None,
>>> obj=cls,
>>> id='admin.E035',
>>> )
>>> ]
>>> else:
>>> return []
>>>
>>> If the thumbnail fields were defined as methods on the ExampleAdmin, all 
>>> would be fine e.g.:
>>>
>>> class ExampleAdmin(models.ModelAdmin):
>>>fields = ['image', 'image_thumbnail']
>>>
>>>def image_thumbnail(self, obj):
>>>return "" % obj.image.url 
>>>
>>> That's fine, but if there's lots of image fields (with a variety of 
>>> names) spread over several ModelAdmin classes, then you end up with a lot 
>>> of 

Re: django 1.8 customize site title

[frocco]

Thank you for sharing this.

On Monday, May 4, 2015 at 12:46:08 PM UTC-4, André Luiz wrote:
>
> You can do it in in urls.py for example[1]
>
> [1]: https://gist.github.com/dvl/0bed149bee4556b32d7a
>
> 2015-05-02 5:55 GMT-03:00 drakkan :
>
>> Hi,
>>
>> I would like to customize django 1.8 site title without override the 
>>  template using AdminSite,
>>
>> I customized AdminSite as per doc here:
>>
>>
>> https://docs.djangoproject.com/en/1.8/ref/contrib/admin/#customizing-the-adminsite-class
>>
>> this seems to work, however the html title still has "Django 
>> administration", 
>>
>> I added site_header and site_title to AdminSite, is this a bug or am I 
>> doing something wrong?
>>
>> here is the html
>>
>> Django administration | MyCustomTitle
>> 
>>
>>
>> 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...@googlegroups.com .
>> To post to this group, send email to django...@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/6668d66c-4235-47a0-933c-0a81e50142b2%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 http://groups.google.com/group/django-users.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-users/da136f79-158f-4012-887c-512541f9c786%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: CSRF cookie not set issue

[monoBOT]

show us the base_1.html

2015-09-10 16:18 GMT+01:00 :

> By the way, I am using Django 1.8.3 (final)
>
>
> On Thursday, September 10, 2015 at 8:16:11 AM UTC-7, kany...@fonality.com
> wrote:
>>
>> First of all I have done my research and found no reasonable explanation
>> for my issue. I have a site on heroku that works fine on the first page,
>> but when I click a button that I have programmed to go to another page, I
>> obtain the infamous CSRF error. The reason for this error is CSRF cookie is
>> not set. Here is a description of the background work done on the dev side:
>>
>> 1. Settings.py
>>
>> MIDDLEWARE_CLASSES = (
>> 'django.contrib.sessions.middleware.SessionMiddleware',
>> 'django.middleware.common.CommonMiddleware',
>> 'django.middleware.csrf.CsrfViewMiddleware',
>> 'django.contrib.auth.middleware.AuthenticationMiddleware',
>> 'django.contrib.auth.middleware.SessionAuthenticationMiddleware',
>> 'django.contrib.messages.middleware.MessageMiddleware',
>> 'django.middleware.clickjacking.XFrameOptionsMiddleware',
>> #'django.middleware.security.SecurityMiddleware',
>>  'django.middleware.csrf.CsrfViewMiddleware',
>> )
>>
>> 2. base.py
>>
>> 
>> {% csrf_token %}
>>
>> 
>> 
>> 
>> 
>> 
>>   > placeholder="Password" type="text">
>> 
>> 
>> 
>>
>> > type="button" onClick ="logIn();">Log In
>>
>> 
>>
>>   
>>
>> 3. views.py
>>
>> def menu(request):
>>
>> return render_to_response('home/base_1.html', context_instance =
>> RequestContext(request, {}) )
>>
>> 4. javascript for the function logIn() that is executed when the button
>> is clicked from (2)
>>
>>
>> function logIn ()
>> {
>> alert('Form has been submitted');
>> document.getElementById('loginform').submit();
>> }
>>
>> I am seriously bewildered and cannot understand why the base_1.html site
>> is not being rendered and I am getting this CSRF error ! Please help 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 http://groups.google.com/group/django-users.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/django-users/14ec3bc1-c7ff-4d3e-8065-9eae959720fc%40googlegroups.com
> 
> .
>
> For more options, visit https://groups.google.com/d/optout.
>



-- 
*monoBOT*
Visite mi sitio(Visit my site): monobotsoft.es/blog/

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

Re: DJANGO

[Arindam sarkar]

The django tutorial itselt
https://docs.djangoproject.com/en/1.8/intro/tutorial01/
On Thu, Sep 10, 2015 at 8:00 PM, Nishant Shetty 
wrote:

> BEST DJANGO TUTORIAL ON WEB?
>
> --
> 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/e00fdb5d-2d0c-4b34-8ebc-d794ec46ed1d%40googlegroups.com
> 
> .
> For more options, visit https://groups.google.com/d/optout.
>



-- 
Regards,

Arindam

Contact no. 08732822385

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

Re: CSRF cookie not set issue

[kanyanwu]

By the way, I am using Django 1.8.3 (final)

On Thursday, September 10, 2015 at 8:16:11 AM UTC-7, kany...@fonality.com 
wrote:
>
> First of all I have done my research and found no reasonable explanation 
> for my issue. I have a site on heroku that works fine on the first page, 
> but when I click a button that I have programmed to go to another page, I 
> obtain the infamous CSRF error. The reason for this error is CSRF cookie is 
> not set. Here is a description of the background work done on the dev side:
>
> 1. Settings.py
>
> MIDDLEWARE_CLASSES = (
> 'django.contrib.sessions.middleware.SessionMiddleware',
> 'django.middleware.common.CommonMiddleware',
> 'django.middleware.csrf.CsrfViewMiddleware',
> 'django.contrib.auth.middleware.AuthenticationMiddleware',
> 'django.contrib.auth.middleware.SessionAuthenticationMiddleware',
> 'django.contrib.messages.middleware.MessageMiddleware',
> 'django.middleware.clickjacking.XFrameOptionsMiddleware',
> #'django.middleware.security.SecurityMiddleware',
>  'django.middleware.csrf.CsrfViewMiddleware',
> )
>
> 2. base.py
>
>  
> {% csrf_token %}
>
> 
>   
> 
> 
> 
>placeholder="Password" type="text">
>
> 
>
>
>  type="button" onClick ="logIn();">Log In
>
> 
>
>   
>
> 3. views.py
>
> def menu(request):
>
> return render_to_response('home/base_1.html', context_instance = 
> RequestContext(request, {}) )
>
> 4. javascript for the function logIn() that is executed when the button is 
> clicked from (2)
>
>
> function logIn ()
> {
> alert('Form has been submitted');
> document.getElementById('loginform').submit();
> }
>
> I am seriously bewildered and cannot understand why the base_1.html site 
> is not being rendered and I am getting this CSRF error ! Please help 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 http://groups.google.com/group/django-users.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-users/14ec3bc1-c7ff-4d3e-8065-9eae959720fc%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

CSRF cookie not set issue

[kanyanwu]

First of all I have done my research and found no reasonable explanation 
for my issue. I have a site on heroku that works fine on the first page, 
but when I click a button that I have programmed to go to another page, I 
obtain the infamous CSRF error. The reason for this error is CSRF cookie is 
not set. Here is a description of the background work done on the dev side:

1. Settings.py

MIDDLEWARE_CLASSES = (
'django.contrib.sessions.middleware.SessionMiddleware',
'django.middleware.common.CommonMiddleware',
'django.middleware.csrf.CsrfViewMiddleware',
'django.contrib.auth.middleware.AuthenticationMiddleware',
'django.contrib.auth.middleware.SessionAuthenticationMiddleware',
'django.contrib.messages.middleware.MessageMiddleware',
'django.middleware.clickjacking.XFrameOptionsMiddleware',
#'django.middleware.security.SecurityMiddleware',
 'django.middleware.csrf.CsrfViewMiddleware',
)

2. base.py

 
{% csrf_token %}


  



  
   

   

Log In



  

3. views.py

def menu(request):

return render_to_response('home/base_1.html', context_instance = 
RequestContext(request, {}) )

4. javascript for the function logIn() that is executed when the button is 
clicked from (2)


function logIn ()
{
alert('Form has been submitted');
document.getElementById('loginform').submit();
}

I am seriously bewildered and cannot understand why the base_1.html site is 
not being rendered and I am getting this CSRF error ! Please help 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 http://groups.google.com/group/django-users.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-users/e016d6f9-875e-4f51-a6cb-b38a6cda2a73%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

DJANGO

[Nishant Shetty]

BEST DJANGO TUTORIAL ON WEB?

-- 
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/e00fdb5d-2d0c-4b34-8ebc-d794ec46ed1d%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: What frontend-tools to use for a new CRM project? Shall I use Django OR switch to Meteor.js?

[ThomasTheDjangoFan]

Hi guys,

on my journey to picking my js-framework I am now trying out React.js and I 
opened this thread in search for good tutorials 
https://groups.google.com/forum/#!topic/django-users/NxDOYhqqQJw .
I guess I'll also have a look at the angular stuff.

This really is about having good tutorials - I need a good tutorial to get 
me started. 
It's a real pity that there seems to be nothing available for React.js ...

Thanks a lot for your help so far!

Kind regards
Thomas

-- 
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/0db1c6ab-78a3-4949-86d2-d975700817d6%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Any good tutorials for django-rest-framework and React.Js?

[ThomasTheDjangoFan]

Hi guys,

I'm trying to get my head into how to use React.Js with Django.

I did the tutorial http://facebook.github.io/react/docs/tutorial.html
in combination with checking out 
https://github.com/HorizonXP/react-tutorial-django,
which is an implementation if it with running django 1.6.

I'm having problems getting the connection to django-rest-framework running 
for CRUD Stuff.

Are there any more *tutorials* available on how to implement an application 
*with React.js and Django-Rest-Framework?*

Kind regards
Thomas

-- 
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/ddce916a-6e8a-4eb1-980e-ecf35230%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Customization in User Add screen

[Tom Lockhart]

> On Sep 9, 2015, at 22:36, Pawanesh Gautam  wrote:
> 
> how to add extra field in user add screen ?? 

afaik you will need to use your own form (in forms.py) which includes the 
fields you want.

hth

- Tom

-- 
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/23DB57A8-61C2-48A6-A105-6409A187427F%40gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: What frontend-tools to use for a new CRM project? Shall I use Django OR switch to Meteor.js?

[Jani Tiainen]

I've been developing with Dojotoolkit and ExtJS. Both integrate with 
Django as well as any other JS framework.



On 10.09.2015 09:47, Mario Gudelj wrote:


+1 angular. Stack overflow is your friend and there's a lot of angular 
on it. You can do a lot with it with basic knowledge as well. And 
template syntax will make sense going to it from django


On 10 Sep 2015 3:53 pm, "Gergely Polonkai" > wrote:


Hello,

this is a bit off topic here, and highly opinion based, but here
are my two cents: I got along very well with both Bootstrap and
Angular, but never tried React before. However, a quick Google
search shows that React is barely supported yet (in terms of
available Django apps).

Best,
Gergely

On 10 Sep 2015 00:29, "ThomasTheDjangoFan"
> wrote:

Yeah, I definetly hate to write Javascript and I really do NOT
want to write server code in it.

*The parts where I really need a javascript framework in my
app are complex forms:
A page might consist of multiple forms bundled with formsets,
inline-forms and so on.*

*The question is:
*Which js-framework has the best form support for django? It
would be cool if I would just have to write server-side
model-variation and the client would adopt it.
Which js-framework has the best tutorial to get myself started?

*I checked out **www.djangopackages.com
 - it seems like I have the
following options:
*Angular.js: made by Google (6 django-pakets on
www.djangopackages.com )
JQuery.js: (4 django-pakets on www.djangopackages.com
)
Ember.js: (3 django-pakets on www.djangopackages.com
)
React.js: made by facebook (0 django-pakets on
www.djangopackages.com )
riot.js: (0 django-pakets on www.djangopackages.com
)

Any suggestions?

Kind regards
Thomas
-- 
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/13e79d83-a4e5-4e6f-a372-47320791d9cd%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 http://groups.google.com/group/django-users.
To view this discussion on the web visit

https://groups.google.com/d/msgid/django-users/CACczBUKWf6knewigf6ax6bheKje2jXUNs5uJ3%3DZ0KgiL2UxAXg%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 http://groups.google.com/group/django-users.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-users/CAHqTbj%3Doas7sNhwK6YbV%3DHGL-j0ELkAwO94eCrUd00Esg_5BhQ%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 

Re: customize app ordering in django admin

['Tom Evans' via Django users]

On Thu, Sep 10, 2015 at 11:50 AM, Pawanesh Gautam  wrote:
> hi
>
> i have list of app (app1,app2.app3,app3,app4).i would like to change the app
> order in admin site so that it will look like dis :
> (app1,app3,app4,app2).
> please suggest some tips to perform this .
>
> thanks

My top tip: Read the django tutorial all the way through:

https://docs.djangoproject.com/en/1.8/intro/tutorial02/#customize-the-admin-index-page

Cheers

Tom

-- 
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/CAFHbX1%2Bjuds5%2ByjLaQEoUhsVwtVF%3DDens72D0CRJcW_BPHiwrA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Adding dynamic methods to ModelAdmin fails in 1.8

[Malcolm Box]

Ticket filed: https://code.djangoproject.com/ticket/25374

On Thursday, 10 September 2015 11:27:13 UTC+1, Malcolm Box wrote:
>
> Hi Simon,
>
> I've tried that, and it still fails the same system check.
>
> The system check checks that all the values returned from 
> get_readonly_fields exist as class attributes on the ModelAdmin (or are 
> callable/fields on model, neither of which helps here). With them being 
> created via __getattr__, they don't.
>
> I'm coming to the conclusion that the right behaviour is to run the system 
> check against an instance, not the class, since that's what the core admin 
> code uses.
>
> Thanks for the offer to review changes - I'll try to put a patch together 
> this week.
>
> Cheers,
>
> Malcolm
>
> On 9 September 2015 at 18:17, Simon Charette <> wrote:
>
>> Hi Malcom,
>>
>> What I meant to suggest is to remove the fields from 
>> `fields`/`readonly_fields` and dynamically return them in the 
>> `get_(fields|readonly_fields)` fields method.
>>
>> e.g.
>>
>> class ThumbnailFieldsAdmin(models.ModelAdmin):
>> fields = []
>> readonly_fields = []
>> thumbnail_fields = []
>>
>> def __getattr__(self, name):
>> if name.endswith('_thumbnail'):
>> return thumbnail_function
>> raise AttributeError
>>
>> def get_fields(request, obj=None):
>> fields = super(ThumbnailFieldsAdmin, self).get_fields(request, 
>> obj=obj)
>> return self.thumbnail_fields + fields
>>
>> def get_readonly_fields(request, obj=None):
>> readonly_fields = super(ThumbnailFieldsAdmin, self).get_fields(
>> request, obj=obj)
>> return readonly_fields + thumbnail_fields
>>
>> But I'm afraid that you'll have to rely on metaclass programming if you 
>> want the order of fields to be maintained somehow.
>>
>> > I therefore suspect that the check is actually borked, and it should be 
>> checking hasattr(instance, field_name) rather than hasattr(cls, field_name)
>>
>> The thing is checks are run against ModelAdmin classes and not the 
>> instances bound to the site they were registered to 
>> .
>>  
>> You could submit a feature request to actually run the test against the 
>> instances but since this is really and edge case you'd have to provide a 
>> patch/PR if you don't want the ticket to rot in Trac make it to Django 1.9 
>> which should enter feature freeze soon enough. I'd be glad to review your 
>> proposed changes if you're interested.
>>
>> Simon
>>
>>
>> Le mercredi 9 septembre 2015 10:31:12 UTC-4, Malcolm Box a écrit :
>>
>>> Hi Simon,
>>>
>>> Thanks for the pointer, but I don't think that helps.
>>>
>>> The fields are already declared using the existing fields / 
>>> readonly_fields attributes on the ExampleAdmin class - and this is what 
>>> get_fields / get_readonly_fields return. The system check fails because the 
>>> fields declared don't exist on the ExampleAdmin class nor on the model. 
>>> Here's the relevant lines from contrib/admin/checks.py:
>>>
>>> def _check_readonly_fields_item(self, cls, model, field_name, label):
>>> if callable(field_name):
>>> return []
>>> elif hasattr(cls, field_name):
>>> return []
>>> elif hasattr(model, field_name):
>>> return []
>>> else:
>>> try:
>>> model._meta.get_field(field_name)
>>> except FieldDoesNotExist:
>>> return [
>>> checks.Error(
>>> "The value of '%s' is not a callable, an 
>>> attribute of '%s', or an attribute of '%s.%s'." % (
>>> label, cls.__name__, model._meta.app_label, 
>>> model._meta.object_name
>>> ),
>>> hint=None,
>>> obj=cls,
>>> id='admin.E035',
>>> )
>>> ]
>>> else:
>>> return []
>>>
>>> If the thumbnail fields were defined as methods on the ExampleAdmin, all 
>>> would be fine e.g.:
>>>
>>> class ExampleAdmin(models.ModelAdmin):
>>>fields = ['image', 'image_thumbnail']
>>>
>>>def image_thumbnail(self, obj):
>>>return "" % obj.image.url 
>>>
>>> That's fine, but if there's lots of image fields (with a variety of 
>>> names) spread over several ModelAdmin classes, then you end up with a lot 
>>> of duplicated code. The normal solution then is to refactor the code. And 
>>> that's where I get stuck - I can't see (short of metaclass programming!) 
>>> how to inject the methods into the class such that the system check 
>>> succeeds.
>>>
>>> I therefore suspect that the check is actually borked, and it should be 
>>> checking hasattr(instance, field_name) rather than hasattr(cls, 
>>> field_name)
>>>
>>> So I see three possibilities, in order of probability:
>>>
>>>

customize app ordering in django admin

[Pawanesh Gautam]

hi

i have list of app (app1,app2.app3,app3,app4).i would like to change the 
app order in admin site so that it will look like dis :
(app1,app3,app4,app2).
please suggest some tips to perform this .

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/203362fb-66d1-4995-a3f0-7a03cae3dec5%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Adding dynamic methods to ModelAdmin fails in 1.8

[Malcolm Box]

Hi Simon,

I've tried that, and it still fails the same system check.

The system check checks that all the values returned from
get_readonly_fields exist as class attributes on the ModelAdmin (or are
callable/fields on model, neither of which helps here). With them being
created via __getattr__, they don't.

I'm coming to the conclusion that the right behaviour is to run the system
check against an instance, not the class, since that's what the core admin
code uses.

Thanks for the offer to review changes - I'll try to put a patch together
this week.

Cheers,

Malcolm

On 9 September 2015 at 18:17, Simon Charette  wrote:

> Hi Malcom,
>
> What I meant to suggest is to remove the fields from
> `fields`/`readonly_fields` and dynamically return them in the
> `get_(fields|readonly_fields)` fields method.
>
> e.g.
>
> class ThumbnailFieldsAdmin(models.ModelAdmin):
> fields = []
> readonly_fields = []
> thumbnail_fields = []
>
> def __getattr__(self, name):
> if name.endswith('_thumbnail'):
> return thumbnail_function
> raise AttributeError
>
> def get_fields(request, obj=None):
> fields = super(ThumbnailFieldsAdmin, self).get_fields(request, obj
> =obj)
> return self.thumbnail_fields + fields
>
> def get_readonly_fields(request, obj=None):
> readonly_fields = super(ThumbnailFieldsAdmin, self).get_fields(
> request, obj=obj)
> return readonly_fields + thumbnail_fields
>
> But I'm afraid that you'll have to rely on metaclass programming if you
> want the order of fields to be maintained somehow.
>
> > I therefore suspect that the check is actually borked, and it should be
> checking hasattr(instance, field_name) rather than hasattr(cls, field_name)
>
> The thing is checks are run against ModelAdmin classes and not the
> instances bound to the site they were registered to
> .
> You could submit a feature request to actually run the test against the
> instances but since this is really and edge case you'd have to provide a
> patch/PR if you don't want the ticket to rot in Trac make it to Django 1.9
> which should enter feature freeze soon enough. I'd be glad to review your
> proposed changes if you're interested.
>
> Simon
>
>
> Le mercredi 9 septembre 2015 10:31:12 UTC-4, Malcolm Box a écrit :
>
>> Hi Simon,
>>
>> Thanks for the pointer, but I don't think that helps.
>>
>> The fields are already declared using the existing fields /
>> readonly_fields attributes on the ExampleAdmin class - and this is what
>> get_fields / get_readonly_fields return. The system check fails because the
>> fields declared don't exist on the ExampleAdmin class nor on the model.
>> Here's the relevant lines from contrib/admin/checks.py:
>>
>> def _check_readonly_fields_item(self, cls, model, field_name, label):
>> if callable(field_name):
>> return []
>> elif hasattr(cls, field_name):
>> return []
>> elif hasattr(model, field_name):
>> return []
>> else:
>> try:
>> model._meta.get_field(field_name)
>> except FieldDoesNotExist:
>> return [
>> checks.Error(
>> "The value of '%s' is not a callable, an
>> attribute of '%s', or an attribute of '%s.%s'." % (
>> label, cls.__name__, model._meta.app_label,
>> model._meta.object_name
>> ),
>> hint=None,
>> obj=cls,
>> id='admin.E035',
>> )
>> ]
>> else:
>> return []
>>
>> If the thumbnail fields were defined as methods on the ExampleAdmin, all
>> would be fine e.g.:
>>
>> class ExampleAdmin(models.ModelAdmin):
>>fields = ['image', 'image_thumbnail']
>>
>>def image_thumbnail(self, obj):
>>return "" % obj.image.url
>>
>> That's fine, but if there's lots of image fields (with a variety of
>> names) spread over several ModelAdmin classes, then you end up with a lot
>> of duplicated code. The normal solution then is to refactor the code. And
>> that's where I get stuck - I can't see (short of metaclass programming!)
>> how to inject the methods into the class such that the system check
>> succeeds.
>>
>> I therefore suspect that the check is actually borked, and it should be
>> checking hasattr(instance, field_name) rather than hasattr(cls,
>> field_name)
>>
>> So I see three possibilities, in order of probability:
>>
>>1. I'm being dumb, and there's an easy way to dynamically create
>>attributes on a ModelAdmin that passes system checks
>>2. The system check is incorrect, and should allow dynamically
>>created attributes on ModelAdmin when validating fields
>>3. Metaclass programming is 

Re: Dynamically alter a list based on selections on other widgets

[Derek]

Try using Django smart selects:

https://pypi.python.org/pypi/django-smart-selects/1.1.1


On Tuesday, 8 September 2015 18:45:07 UTC+2, Baktha Muralidharan wrote:
>
> Hello
>
> I am looking to develop a GUI (Form?) in which I can display a list the 
> contents of which change on the fly as the user makes other selections. For 
> example, there could be a radio button (a simple yes/no button) - based on 
> the selection, the displayed list needs to change dynamically.
> the list could be too long and so, I would like to display it as a 
> scrollable list.
>
> Tips/thoughts on how I could accomplish this will be much appreciated. Of 
> course, if someone has implemented and is willing to share the code, that 
> will be much appreciated as well!
>
> Thanks in advance,
> /Baktha
>

-- 
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/3da1ab35-f911-4de6-9f04-a6fe0c738b0e%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Possible bug in interaction between 'block' and 'include' in Django Templates

[Suriya Subramanian]

I got the answer on IRC that this is not a bug as explained in the 
documentation for 
include https://docs.djangoproject.com/en/1.8/ref/templates/builtins/#include

Suriya

On Thursday, September 10, 2015 at 2:55:42 PM UTC+5:30, Suriya Subramanian 
wrote:
>
> Hi,
>
> I think there is a bug in how 'block' and 'include' template tags interact 
> in the Django Template Language. I have created a Gist showing this issue: 
> https://gist.github.com/anonymous/2627bb35955db77dbfaa
>
> The order of the files in the Gist can be a bit confusing. I will explain 
> what I am trying to do here. I have a base template that defines two 
> blocks, one block directly, and one block within an included file. A child 
> template extends the base template and defines both the blocks. However, in 
> the rendered output the child is able to override only of the blocks. The 
> child template is unable to override the block defined in the include file.
>
> My understand is that, a file and block included within a parent template 
> should be considered a part of the parent. However, that does not seem to 
> be the case.
>
> Thanks,
> Suriya
>

-- 
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/5ee79ae1-9d6f-41de-aa23-369d3104e455%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Possible bug in interaction between 'block' and 'include' in Django Templates

[Suriya Subramanian]

Hi,

I think there is a bug in how 'block' and 'include' template tags interact 
in the Django Template Language. I have created a Gist showing this 
issue: https://gist.github.com/anonymous/2627bb35955db77dbfaa

The order of the files in the Gist can be a bit confusing. I will explain 
what I am trying to do here. I have a base template that defines two 
blocks, one block directly, and one block within an included file. A child 
template extends the base template and defines both the blocks. However, in 
the rendered output the child is able to override only of the blocks. The 
child template is unable to override the block defined in the include file.

My understand is that, a file and block included within a parent template 
should be considered a part of the parent. However, that does not seem to 
be the case.

Thanks,
Suriya

-- 
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/e133b1b0-12aa-4496-84ec-f76dab24bc28%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Hide specific users from auth user model for non super users

[Xavier Palacín Ayuso]

I solve this overrite a UserAdmin class of admin.ModelAdmin:

from django.contrib.auth.admin import UserAdmin
from django.contrib.auth.models import User
from django.utils.translation import ugettext, ugettext_lazy as _
from django.core.exceptions import PermissionDenied


class UserAdmin(admin.ModelAdmin):
# Hide super user for no super user's (Pre-populating data)
def queryset(self, request):
if request.user.is_superuser:
return User.objects.all()
return User.objects.filter(is_superuser=False)


El miércoles, 9 de septiembre de 2015, 17:42:10 (UTC+2), Xavier Palacín 
Ayuso escribió:
>
> I need hide a super admin's users from auth user model of Django of list 
> users template for a normal users or no super admin users.
>

-- 
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/779ae0a5-4315-4d19-9d26-fb92e53e0028%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Get current user in model signal pre_save

[Xavier Palacín Ayuso]

Finally overrite a UserAdmin ModelAdmin:

from django.contrib.auth.admin import UserAdmin
from django.contrib.auth.models import User
from django.utils.translation import ugettext, ugettext_lazy as _
from django.core.exceptions import PermissionDenied


class UserAdmin(admin.ModelAdmin):
actions = ['delete_model']
def get_fieldsets(self, request, obj=None):
if not obj:
return self.add_fieldsets


if request.user.is_superuser:
perm_fields = ('is_active', 'is_staff', 'is_superuser',
   'groups', 'user_permissions')
else:
# modify these to suit the fields you want your
# staff user to be able to edit
perm_fields = ('is_active', 'is_staff', 'groups')


return [(None, {'fields': ('username', 'password')}),
(_('Personal info'), {'fields': ('first_name', 'last_name', 
'email')}),
(_('Permissions'), {'fields': perm_fields}),
(_('Important dates'), {'fields': ('last_login', 
'date_joined')})]


# Prevent super user edition for no super users
def save_model(self, request, obj, form, change):
print 'save_model'
if not change:
# New user
obj.save()
else:
# Update user
if obj.is_superuser:
if request.user.is_superuser:
obj.save()
else:
raise PermissionDenied
else:
obj.save()


def get_actions(self, request):
actions = super(UserAdmin, self).get_actions(request)
del actions['delete_selected']
return actions


# Prevent super user deletion for no super users  
def delete_model(modeladmin, request, queryset):
for obj in queryset:
if obj.is_superuser:
if request.user.is_superuser:
# obj.delete()
else:
raise PermissionDenied
else:
# obj.delete()
delete_model.short_description = 'Eliminar usuario/s seleccionados'


El miércoles, 9 de septiembre de 2015, 12:00:18 (UTC+2), Xavier Palacín 
Ayuso escribió:
>
> I want to collects current user in model signal pre_save, to prevent 
> remove super user permission to current super users.
> As I have now so I can not give administrative privileges to a normal user.
>
> from django.db.models.signals import pre_delete, pre_save, post_save
> from django.dispatch.dispatcher import receiver
> from django.contrib.auth.models import User
> from django.core.exceptions import PermissionDenied
>
>
> @receiver(pre_save, sender=User)
> def save_user(sender, instance, **kwargs):
> if instance._state.adding is True:
> # we would need to create the object
> print "Creating an object"
> else:
> #we are updating the object
> if instance.is_superuser:
> raise PermissionDenied
>
>

-- 
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/8774dcd4-4018-46eb-96f7-a1095cb2eb05%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: What frontend-tools to use for a new CRM project? Shall I use Django OR switch to Meteor.js?

[Mario Gudelj]

+1 angular. Stack overflow is your friend and there's a lot of angular on
it. You can do a lot with it with basic knowledge as well. And template
syntax will make sense going to it from django
On 10 Sep 2015 3:53 pm, "Gergely Polonkai"  wrote:

> Hello,
>
> this is a bit off topic here, and highly opinion based, but here are my
> two cents: I got along very well with both Bootstrap and Angular, but never
> tried React before. However, a quick Google search shows that React is
> barely supported yet (in terms of available Django apps).
>
> Best,
> Gergely
> On 10 Sep 2015 00:29, "ThomasTheDjangoFan" <
> stefan.eichholz.ber...@googlemail.com> wrote:
>
>> Yeah, I definetly hate to write Javascript and I really do NOT want to
>> write server code in it.
>>
>>
>> *The parts where I really need a javascript framework in my app are
>> complex forms:A page might consist of multiple forms bundled with formsets,
>> inline-forms and so on.*
>>
>>
>> *The question is:*Which js-framework has the best form support for
>> django? It would be cool if I would just have to write server-side
>> model-variation and the client would adopt it.
>> Which js-framework has the best tutorial to get myself started?
>>
>> *I checked out *
>> *www.djangopackages.com  - it seems like I
>> have the following options:*Angular.js: made by Google (6 django-pakets
>> on www.djangopackages.com)
>> JQuery.js: (4 django-pakets on www.djangopackages.com)
>> Ember.js: (3 django-pakets on www.djangopackages.com)
>> React.js: made by facebook (0 django-pakets on www.djangopackages.com)
>> riot.js: (0 django-pakets on www.djangopackages.com)
>>
>> Any suggestions?
>>
>> Kind regards
>> Thomas
>>
>> --
>> 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/13e79d83-a4e5-4e6f-a372-47320791d9cd%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 http://groups.google.com/group/django-users.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/django-users/CACczBUKWf6knewigf6ax6bheKje2jXUNs5uJ3%3DZ0KgiL2UxAXg%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 http://groups.google.com/group/django-users.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-users/CAHqTbj%3Doas7sNhwK6YbV%3DHGL-j0ELkAwO94eCrUd00Esg_5BhQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.