Re: Image input missing from POST request

[Abhishek Batra]

Hi Collin,

Thanks for taking time out to look at this. It turns out that I somehow I 
copied the rendered HTML wrong! The real problem was that the form id used 
in input was incorrect and this was the reason for the file not getting 
uploaded.

Separately, this is not really a trick but a fairly standard technique 
nowadays, and after correcting my mistake, it works just fine.

Thanks,
Abhishek

On Tuesday, November 25, 2014 7:08:07 AM UTC+5:30, Collin Anderson wrote:
>
> Hi,
>
> I certainly am learning something new about . 
> However, it may be that that trick simply doesn't work correctly for file 
> fields. My question is: _does_ it work correctly when the  is a 
> child of the ?
>
> Collin
>
> On Saturday, November 22, 2014 1:21:32 PM UTC-5, Abhishek Batra wrote:
>>
>> Hey Donarb,
>>
>> Input fields are not required to be inside form elements, so long as they 
>> specify the form attribute as I have done. Check the form attribute here 
>>  
>> for reference.
>> Moreover, I have other input fields as well which are outside the form 
>> element, but they get successfully submitted.
>>
>> Any other suggestions anyone?
>>
>> Thanks,
>> Abhishek
>>
>> On Saturday, November 22, 2014 11:03:39 PM UTC+5:30, donarb wrote:
>>>
>>> On Friday, November 21, 2014 7:56:54 PM UTC-8, Abhishek Batra wrote:

 Hi,

 This is probably not a Django issue, but just trying my luck.

 I have an input field corresponding to a Django ImageField in a Django 
 template. Rendered, the HTML looks like:

 >>>   method="post" 
   id="profile_form"
   enctype="multipart/form-data">
 ... (other input fields and elements)>>> id="id_profile_pic" name="profile_pic" type="file" />

 The corresponding View is an UpdateView. I found request.FILES to be 
 empty and request.cleaned_data to contain 'profile_pic': None.

 I used firebug to track the POST data. It contained other fields but 
 not profile_pic.

 Can anyone say why the file does not get uploaded? I've posted this 
 question to StakOverflow 
 
  as 
 well, in case someone wants reputation points.

 Thanks,
 Abhishek Batra

>>>
>>>
>>> The input field is outside the closing  tag so would not be 
>>> uploaded as part of the form. 
>>>
>>

-- 
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/aea0cc13-0b33-4734-b59f-a4f06ae12c14%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Preventing race conditions when submitting forms

[donarb]

On Tuesday, November 25, 2014 7:57:08 AM UTC-8, Paul Johnston wrote:
>
> Hi,
>
> Consider an e-commerce site, where Alice and Bob are both editing the 
> product listings. Alice is improving descriptions, while Bob is updating 
> prices. They start editing the Acme Wonder Widget at the same time. Bob 
> finishes first and saves the product with the new price. Alice takes a bit 
> longer to update the description, and when she finishes, she saves the 
> product with her new description. Unfortunately, she also overwrites the 
> price with the old price, which was not intended.
>
> It's worth noting that the controller methods are thread-safe in 
> themselves. They use database transactions, which make them safe in the 
> sense that if Alice and Bob try to save at the precise same moment, it 
> won't cause corruption. The race condition arises from Alice or Bob having 
> stale data in their browser.
>
> Does Django have any way to prevent these race conditions? Just rejecting 
> the second edit with an "edit conflict" message would be a start - although 
> some intelligent merging would be even better.
>
> Thanks,
>
> Paul
>

Another option to consider for the problem you describe is to separate the 
product description and pricing into separate tables linked by foreign key, 
then restrict editing of each based on the user's group permission. I'm 
currently working on a sort of B2B e-commerce project where pricing can be 
different for each customer based on contract agreements (10 or so prices 
per product right now). We don't yet have a need for separate staff to edit 
products and prices, but the capability is there if it's ever needed.

-- 
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/68d0d761-6b67-4fe0-b8b7-71c12a31b0b7%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: ModelAdmin.has_change_permission gives 403

[Mike Dewhirst]

On 26/11/2014 11:59 AM, Mike Dewhirst wrote:

From the docs ...

https://docs.djangoproject.com/en/1.6/ref/contrib/admin/#django.contrib.admin.ModelAdmin.has_change_permission

... is working nicely except it just pops up a standard error page
403 Forbidden when it returns False.



Actually, I must have changed my code and refreshed an already rendered 
form when I thought it was working. Just clicking on the wrong model in 
the admin list pops up a 403 Forbidden page. It looks like 
ModelAdmin.has_change_permission() must return True to render the change 
form.


Maybe someone can tell me how to make a model read-only for certain
users based on their relationship with the model?

To elaborate somewhat, a company owns a substance displayed on a page in 
the admin and any user should be able to see it but only users who are 
members of the same company may change or delete it.


Thanks



How can I intercept this in the Admin and treat it like an error
displayed like all the other validation errors generated from the
model.clean() method???

I'd like to raise a business rule violation exception on saving the
model.

Thanks for any hints

Mike



--
You received this message because you are subscribed to the Google Groups "Django 
users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-users+unsubscr...@googlegroups.com.
To post to this group, send email to django-users@googlegroups.com.
Visit this group at http://groups.google.com/group/django-users.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-users/547546E6.4070206%40dewhirst.com.au.
For more options, visit https://groups.google.com/d/optout.

Re: Unit-testing Custom Admin Action, requires request and querysets parameters.

[Azam Alias]

Hi Collin,

I apologise for the late update. Didnt get any notifications from your 
reply.

I have solved this issue as per your suggestion. Pasting the solution for 
others' reference. 

Thanks !

from django.test import TestCase
from django.contrib.admin.sites import AdminSite
from batch_apps.models import App
from batch_apps.admin import AppAdmin


class MockRequest(object):
pass

request = MockRequest()


class AppAdminTest(TestCase):

def setUp(self):
self.app_admin = AppAdmin(App, AdminSite())

def test_activate_apps_should_activate_inactive_app(self):
app1 = App.objects.create(name='Inactive App 001', is_active=False)
queryset = App.objects.filter(pk=1)
self.app_admin.activate_apps(request, queryset)
self.assertTrue(App.objects.get(pk=1).is_active)

def test_deactivate_apps_should_deactivate_active_app(self):
app1 = App.objects.create(name='Active App 001', is_active=True)
queryset = App.objects.filter(pk=1)
self.app_admin.deactivate_apps(request, queryset)
self.assertFalse(App.objects.get(pk=1).is_active)



On Thursday, 6 November 2014 01:05:13 UTC+8, Collin Anderson wrote:
>
> Hello,
>
> Would it work to import AppAdmin, instantiate it, and then call the 
> methods in a unit test?
>
> Collin
>  
>

-- 
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/2f79f583-99a9-4d1c-b384-9733bbf98ec0%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

ModelAdmin.has_change_permission gives 403

[Mike Dewhirst]

From the docs ...

https://docs.djangoproject.com/en/1.6/ref/contrib/admin/#django.contrib.admin.ModelAdmin.has_change_permission

... is working nicely except it just pops up a standard error page 403 
Forbidden when it returns False.


How can I intercept this in the Admin and treat it like an error 
displayed like all the other validation errors generated from the 
model.clean() method???


I'd like to raise a business rule violation exception on saving the model.

Thanks for any hints

Mike

--
You received this message because you are subscribed to the Google Groups "Django 
users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-users+unsubscr...@googlegroups.com.
To post to this group, send email to django-users@googlegroups.com.
Visit this group at http://groups.google.com/group/django-users.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-users/5475260D.609%40dewhirst.com.au.
For more options, visit https://groups.google.com/d/optout.

Re: Upgrading Django (to 1.7)

[Andrew Pinkham]

Hi,
Upgrading Django (to 1.7) Part IV: Upgrade Strategies is now available!

For the article:
 afrg.co/updj17/a4/

For all of the material:
 afrg.co/updj17/

I've also provided a checklist of upgrade steps, as well as a list of all the 
links used throughout the series:
 afrg.co/updj17/cl/
 afrg.co/updj17/l/ 

Any feedback appreciated. I hope you find the material helpful.

Andrew

-- 
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/73E604D5-964A-48CE-A0ED-F0856DE5AD2B%40andrewsforge.com.
For more options, visit https://groups.google.com/d/optout.

Re: Preventing race conditions when submitting forms

[Cal Leeming]

+1 - conflict resolution is not an easy task, and really depends on your
business logic/use case.

It's worth mentioning that the approach django-concurrency uses may not be
suitable for your use case, and in my opinion implementing this restriction
on a per model basis is not the best approach, especially when handling
multiple model scenarios. Also the implementation of django-concurrency is
"dumb", if you look at the example it blocks two save() calls despite no
fields being changed on them, and I suspect it doesn't attempt to do any
sort of checks to see if the updates would have conflicted. This in itself
would be enough reason to stay away from the library (if I'm mistaken, let
me know).

django-locking is even worse, it uses a shotgun approach of locking the
entire model.. I've used systems (as a user) in the past which implement a
similar locking system, and they are a UX anti pattern (imho).

Also remember that representing conflicts in the UI is quite important,
having an error at the top of the page telling you that a field conflicted
really is quite ghetto and doesn't give a good user experience.. Trello
handles this nicely, but they put a lot of time/effort into making the
whole process seamless.

The above doesn't really answer your original question of "what can I do",
but I hope it gives you some insight into the downsides of those other
options.

Cal

On Tue, Nov 25, 2014 at 9:10 PM, Simon Charette 
wrote:

> I can't think of a generic way of solving conflict resolution. I'd say
> it's highly application specific.
>
> Le mardi 25 novembre 2014 15:06:53 UTC-5, Paul Johnston a écrit :
>
>> Tim, Simon,
>>
>> Thanks for the responses. Looks like django-concurrency is a good fit,
>> and it works the way Tim suggested (so no need to write your own mixins!)
>>
>> One follow-up question: do you have any ideas for conflict resolution?
>> The django-concurrency resolution is pretty basic, but it would be a lot of
>> work to do something better.
>>
>> Paul
>>
>>
>> On Tuesday, November 25, 2014 6:59:15 PM UTC, Tim Chase wrote:
>>>
>>> On 2014-11-25 07:57, Paul Johnston wrote:
>>> > Consider an e-commerce site, where Alice and Bob are both editing
>>> > the product listings. Alice is improving descriptions, while Bob is
>>> > updating prices. They start editing the Acme Wonder Widget at the
>>> > same time. Bob finishes first and saves the product with the new
>>> > price. Alice takes a bit longer to update the description, and when
>>> > she finishes, she saves the product with her new description.
>>> > Unfortunately, she also overwrites the price with the old price,
>>> > which was not intended.
>>>
>>> The common solution in this case your model would have something like
>>> a "last_modified_timestamp" or "last_modified_counter".  This would
>>> be sent with the form and then resubmitted back.  If the
>>> timestamp/counter is the same, you know it's safe to update the
>>> timestamp or increment the counter (done within the transaction to
>>> ensure atomicity).  If it's *not* the same timestamp/counter as it was
>>> when the form was created, you know that it's been modified in the
>>> interim and you can present a conflict-resolution form.
>>>
>>> I don't think Django has anything like this out of the box, but it's
>>> fairly straightforward to implement.  I've done it enough times that
>>> I should just create some model/form mixin to handle it for me.
>>>
>>> -tkc
>>>
>>>
>>>
>>>  --
> 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/1c0c9322-65cc-4c1d-a3bb-e8c80428d0f2%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/CAHKQagEaWY0ASiYsfxnqHadbCQvP12eomRJTtMzNaAfLVUqEaA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: How to deal with CSRF middleware from a crawler

[Torsten Bronger]

Hallöchen!

Carl Meyer writes:

> [...]
>
> Unless you've modified the CSRF implementation locally, all it
> does is check that the CSRF token provided in a cookie matches the
> one provided in the POST data. [...]
>
> But this means that the CSRF protection is simple to bypass in a
> case like yours: you can just set the CSRF cookie and the POST var
> to the same value in all your crawler's requests. It doesn't
> matter what that value is.

Thank you.  I was ignorant about the details of this anti-CSRF
mechanism.  It's working now, even for the login view itself.

Tschö,
Torsten.

-- 
Torsten BrongerJabber ID: torsten.bron...@jabber.rwth-aachen.de
  or http://bronger-jmp.appspot.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 http://groups.google.com/group/django-users.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-users/87zjbf6khp.fsf%40physik.rwth-aachen.de.
For more options, visit https://groups.google.com/d/optout.

Re: Preventing race conditions when submitting forms

[Simon Charette]

I can't think of a generic way of solving conflict resolution. I'd say it's 
highly application specific.

Le mardi 25 novembre 2014 15:06:53 UTC-5, Paul Johnston a écrit :
>
> Tim, Simon,
>
> Thanks for the responses. Looks like django-concurrency is a good fit, and 
> it works the way Tim suggested (so no need to write your own mixins!)
>
> One follow-up question: do you have any ideas for conflict resolution? The 
> django-concurrency resolution is pretty basic, but it would be a lot of 
> work to do something better.
>
> Paul
>
>
> On Tuesday, November 25, 2014 6:59:15 PM UTC, Tim Chase wrote:
>>
>> On 2014-11-25 07:57, Paul Johnston wrote: 
>> > Consider an e-commerce site, where Alice and Bob are both editing 
>> > the product listings. Alice is improving descriptions, while Bob is 
>> > updating prices. They start editing the Acme Wonder Widget at the 
>> > same time. Bob finishes first and saves the product with the new 
>> > price. Alice takes a bit longer to update the description, and when 
>> > she finishes, she saves the product with her new description. 
>> > Unfortunately, she also overwrites the price with the old price, 
>> > which was not intended. 
>>
>> The common solution in this case your model would have something like 
>> a "last_modified_timestamp" or "last_modified_counter".  This would 
>> be sent with the form and then resubmitted back.  If the 
>> timestamp/counter is the same, you know it's safe to update the 
>> timestamp or increment the counter (done within the transaction to 
>> ensure atomicity).  If it's *not* the same timestamp/counter as it was 
>> when the form was created, you know that it's been modified in the 
>> interim and you can present a conflict-resolution form. 
>>
>> I don't think Django has anything like this out of the box, but it's 
>> fairly straightforward to implement.  I've done it enough times that 
>> I should just create some model/form mixin to handle it for me. 
>>
>> -tkc 
>>
>>
>>
>>

-- 
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/1c0c9322-65cc-4c1d-a3bb-e8c80428d0f2%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Foreign Key Deletion Problem

[Simon Charette]

Hi Jann,

I think you'll need to write a custom deletion handler for this.

The following should work:

from django.db import models


class SetNull(object):
"""Deletion handler that behaves like `SET_NULL` but also
takes a list of extra fields to NULLify."""

def __init__(self, *fields):
self.fields = fields

def __call__(self, collector, field, sub_objs, using):
# Set the field this is attached to NULL
models.SET_NULL(collector, field, sub_objs, using)
for field in self.fields:
models.SET_NULL(collector, field, sub_objs, using)


class MyModel(models.Model):
a = models.CharField(max_length=255, null=True, blank=True)
b = models.ForeignKey(
'MyOtherModel', null=True, blank=True, on_delete=SetNull(a)
)

Simon


Le mardi 25 novembre 2014 12:19:48 UTC-5, Yan a écrit :
>
> Dear Django Users,
>
> I have been running into a problem with the app I am developing and I
> haven't been able to find a good solution. Suppose I have the following
> model:
>
> class MyModel(models.Model):
> a = models.CharField(max_length=255, null=True, blank=True)
> b = models.ForeignKey('MyOtherModel', null=True, blank=True,
> on_delete=models.SET_NULL)
> # some more model fields
>
> The task I am trying to accomplish is the following: If an instance of
> "MyOtherModel" is deleted, a and b of the related MyModel-instance
> should be set to NULL in the database, but the instance of MyModel with
> the other fields should remain. The model above only sets b to NULL but
> not a.
>
> Any ideas?
>
> Regards,
>
> Jann
>
>

-- 
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/7eefc8b9-07c0-44ad-b402-65715506e64d%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Preventing race conditions when submitting forms

[Paul Johnston]

Tim, Simon,

Thanks for the responses. Looks like django-concurrency is a good fit, and 
it works the way Tim suggested (so no need to write your own mixins!)

One follow-up question: do you have any ideas for conflict resolution? The 
django-concurrency resolution is pretty basic, but it would be a lot of 
work to do something better.

Paul


On Tuesday, November 25, 2014 6:59:15 PM UTC, Tim Chase wrote:
>
> On 2014-11-25 07:57, Paul Johnston wrote: 
> > Consider an e-commerce site, where Alice and Bob are both editing 
> > the product listings. Alice is improving descriptions, while Bob is 
> > updating prices. They start editing the Acme Wonder Widget at the 
> > same time. Bob finishes first and saves the product with the new 
> > price. Alice takes a bit longer to update the description, and when 
> > she finishes, she saves the product with her new description. 
> > Unfortunately, she also overwrites the price with the old price, 
> > which was not intended. 
>
> The common solution in this case your model would have something like 
> a "last_modified_timestamp" or "last_modified_counter".  This would 
> be sent with the form and then resubmitted back.  If the 
> timestamp/counter is the same, you know it's safe to update the 
> timestamp or increment the counter (done within the transaction to 
> ensure atomicity).  If it's *not* the same timestamp/counter as it was 
> when the form was created, you know that it's been modified in the 
> interim and you can present a conflict-resolution form. 
>
> I don't think Django has anything like this out of the box, but it's 
> fairly straightforward to implement.  I've done it enough times that 
> I should just create some model/form mixin to handle it for me. 
>
> -tkc 
>
>
>
>

-- 
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/af211069-25e4-4f65-9e69-0afdfc5a54cf%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Upgrading Django (to 1.7)

[Andrew Pinkham]

Hi,
I have just updated Upgrading Django (to 1.7) Part III: Django 1.7's New 
Features. The App Registry and System Check Framework sections have been 
updated to be more accessible.

For the article:
 afrg.co/updj17/a3/

For all of the material:
 afrg.co/updj17/

Part IV will be available before the end of the day!

Andrew

-- 
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/76C8501F-6735-4734-974A-119EE2614B07%40andrewsforge.com.
For more options, visit https://groups.google.com/d/optout.

Re: is it worth going for version 1.6 for commertial project

[Krishnakant Mane]

Well then I would go with 1.7.
Thanks for all the advise.
Happy hacking.
Krishnakant.On 11/25/2014 06:54 PM, Collin Anderson wrote:

Hi All,

If it helps, at work we have upgraded all of our websites to django 1.7,
and are only now starting to think about using migrations.

It's totally possible to use 1.7 without migrations.

It's also worth noting that although Django supports 1.6 for another 4-5
months, that's only for security fixes and data-loss bugs, whereas 1.7 gets
more bug fixes.

Collin


On Saturday, November 22, 2014 7:56:47 PM UTC-5, Thomas wrote:


On Nov 22, 2014, at 4:53 AM, Krishnakant Mane > wrote:


Hello all,
I have been looking for some good discussion on this issue.
i see there is not much difference between 1.7 and 1.6 as far as my

requirement goes.

I have gone through the official docs for both in a kind of rappid

specific way.

As it is I am not going to use ORM at all.

I am sticking with 1.6.x in case the new migration system needs a bit of
extra time to iron out.

But since you are not using the ORM then you will not notice one way or
the other. I’d probably go with 1.7.x…

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

Re: Preventing race conditions when submitting forms

[Tim Chase]

On 2014-11-25 07:57, Paul Johnston wrote:
> Consider an e-commerce site, where Alice and Bob are both editing
> the product listings. Alice is improving descriptions, while Bob is
> updating prices. They start editing the Acme Wonder Widget at the
> same time. Bob finishes first and saves the product with the new
> price. Alice takes a bit longer to update the description, and when
> she finishes, she saves the product with her new description.
> Unfortunately, she also overwrites the price with the old price,
> which was not intended.

The common solution in this case your model would have something like
a "last_modified_timestamp" or "last_modified_counter".  This would
be sent with the form and then resubmitted back.  If the
timestamp/counter is the same, you know it's safe to update the
timestamp or increment the counter (done within the transaction to
ensure atomicity).  If it's *not* the same timestamp/counter as it was
when the form was created, you know that it's been modified in the
interim and you can present a conflict-resolution form.

I don't think Django has anything like this out of the box, but it's
fairly straightforward to implement.  I've done it enough times that
I should just create some model/form mixin to handle it for me.

-tkc



-- 
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/20141125130116.43f68a69%40bigbox.christie.dr.
For more options, visit https://groups.google.com/d/optout.

Foreign Key Deletion Problem

[Jann Haber]

Dear Django Users,

I have been running into a problem with the app I am developing and I
haven't been able to find a good solution. Suppose I have the following
model:

class MyModel(models.Model):
a = models.CharField(max_length=255, null=True, blank=True)
b = models.ForeignKey('MyOtherModel', null=True, blank=True,
on_delete=models.SET_NULL)
# some more model fields

The task I am trying to accomplish is the following: If an instance of
"MyOtherModel" is deleted, a and b of the related MyModel-instance
should be set to NULL in the database, but the instance of MyModel with
the other fields should remain. The model above only sets b to NULL but
not a.

Any ideas?

Regards,

Jann

-- 
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/6f008e52-3e3e-484b-8bca-ec6c1ef263bd%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Preventing race conditions when submitting forms

[Simon Charette]

Hi Paul,

You might want to take a look at the third party packages listed under the 
*concurrency* category 
.

I've used django-concurrency  
in the past and it worked well for me.

Simon

Le mardi 25 novembre 2014 10:57:08 UTC-5, Paul Johnston a écrit :
>
> Hi,
>
> Consider an e-commerce site, where Alice and Bob are both editing the 
> product listings. Alice is improving descriptions, while Bob is updating 
> prices. They start editing the Acme Wonder Widget at the same time. Bob 
> finishes first and saves the product with the new price. Alice takes a bit 
> longer to update the description, and when she finishes, she saves the 
> product with her new description. Unfortunately, she also overwrites the 
> price with the old price, which was not intended.
>
> It's worth noting that the controller methods are thread-safe in 
> themselves. They use database transactions, which make them safe in the 
> sense that if Alice and Bob try to save at the precise same moment, it 
> won't cause corruption. The race condition arises from Alice or Bob having 
> stale data in their browser.
>
> Does Django have any way to prevent these race conditions? Just rejecting 
> the second edit with an "edit conflict" message would be a start - although 
> some intelligent merging would be even better.
>
> Thanks,
>
> Paul
>

-- 
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/0b766b15-d47a-4063-8768-01e70809f4d2%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Preventing race conditions when submitting forms

[Paul Johnston]

Hi,

Consider an e-commerce site, where Alice and Bob are both editing the 
product listings. Alice is improving descriptions, while Bob is updating 
prices. They start editing the Acme Wonder Widget at the same time. Bob 
finishes first and saves the product with the new price. Alice takes a bit 
longer to update the description, and when she finishes, she saves the 
product with her new description. Unfortunately, she also overwrites the 
price with the old price, which was not intended.

It's worth noting that the controller methods are thread-safe in 
themselves. They use database transactions, which make them safe in the 
sense that if Alice and Bob try to save at the precise same moment, it 
won't cause corruption. The race condition arises from Alice or Bob having 
stale data in their browser.

Does Django have any way to prevent these race conditions? Just rejecting 
the second edit with an "edit conflict" message would be a start - although 
some intelligent merging would be even better.

Thanks,

Paul

-- 
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/99ca95b9-af6c-4e75-8ed1-3355a0397acc%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: my mysite/templates/admin/base_site.html is ignored (tutorial unclear?)

[donarb]

On Tuesday, November 25, 2014 5:33:02 AM UTC-8, Collin Anderson wrote:
>
> Hi,
>
> Wow. Everything you've shown looks right.
>
> Here's something to try: replace base_site.html with a completely empty 
> file. That should cause the admin page to be completely blank.
>
> If that works, could you post a snippet of where you're changing the 
> template? Are you changing the  and expecting the  to be 
> different?
>
> Collin
>
>
> On Saturday, November 22, 2014 8:05:30 PM UTC-5, Andreas Ka wrote:
>>
>> Thanks for your help.
>>
>> I really think there is something wrong with that part of the tutorial. A 
>> small thing, but wrong.
>>
>>
>> > Check your settings file, 
>> > are there two TEMPLATE_DIRS variables defined?
>>
>> Nope. 
>>
>>
>> This is where I placed it:
>>
>> ...
>> import os
>> BASE_DIR = os.path.dirname(os.path.dirname(__file__))
>> TEMPLATE_DIRS = [os.path.join(BASE_DIR, 'templates')]
>> ...
>>
>>
>> just tried this:
>>
>> import mysite.settings as settings
>> print settings.TEMPLATE_DIRS
>> ['D:\\Programming\\eclipse\\mysite\\templates']
>>
>> so no: not empty.
>>
>>
>> Why is my file templates/admin/base_site.html never called
>> when I open http://127.0.0.1:8000/admin/ or 
>> http://127.0.0.1:8000/admin/polls/  ?
>>
>>
>> Thanks.
>>
>>
>> On Fri, Nov 21, 2014 at 11:08 PM, donarb  wrote:
>>
>>> On Friday, November 21, 2014 10:59:19 AM UTC-8, Andreas Ka wrote:

 I don't know.
 How to test that?



 The things I have done were these:
 https://docs.djangoproject.com/en/1.7/intro/tutorial02/#
 customizing-your-project-s-templates

 mkdir templates
 mkdir templates/admin
 cp 
 /usr/local/lib/python2.7/dist-packages/django/contrib/admin/templates/admin/base_site.html
  
 templates/admin/

 ls -l templates/admin/base_site.html
 -rw-r--r-- 1 user group 338 Nov 21 18:50 templates/admin/base_site.html
 (and www-data is member of that group)

 nano templates/admin/base_site.html   -> changed it to what I want to 
 see
 nano mysite/settings.py  -->   TEMPLATE_DIRS = [os.path.join(BASE_DIR, 
 'templates')]

 restarted the server.

 On Fri, Nov 21, 2014 at 3:24 AM, Collin Anderson  
 wrote:

> Hi,
>
> Do other templates work in that folder?
>
> Collin
>
>
> On Monday, November 17, 2014 4:12:27 PM UTC-5, Andreas Ka wrote:
>
>>
>> > Show your view code
>> The tutorial did not create any view.py for the admin pages
>>
>>
>>
>> See https://docs.djangoproject.com/en/1.7/intro/tutorial02/#
>> customize-the-admin-look-and-feel
>>
>> We copied from the Django source files these two into:
>> /mysite/templates/admin/base_site.html
>> and
>> /mysite/templates/admin/index.html
>>
>>
>>
>> and in https://docs.djangoproject.com/en/1.7/intro/tutorial02/#c
>> ustomize-the-admin-change-list
>> edited:
>>
>>
>> admin.py
>>
>> from django.contrib import admin
>>
>> # Register your models here.
>>
>> from django.contrib import admin
>> from polls.models import Choice, Question
>>
>>
>> class ChoiceInline(admin.TabularInline):
>> model = Choice
>> extra = 3
>>
>>
>> class QuestionAdmin(admin.ModelAdmin):
>> fieldsets = [
>> (None,   {'fields': ['question_text']}),
>> ('Date information', {'fields': ['pub_date'], 'classes': 
>> ['collapse']}),
>> ]
>> inlines = [ChoiceInline]
>> list_display = ('question_text', 'pub_date', 
>> 'was_published_recently')
>> list_filter = ['pub_date']
>> search_fields = ['question_text']
>>
>> admin.site.register(Question, QuestionAdmin)
>>
>>
>> ---
>>
>>
>>
>> On Mon, Nov 17, 2014 at 2:11 PM, Artie  wrote:
>>
>>> Are you sure about correct path to your templates in views?
>>>
>>> Show your view code
>>>
>>> понедельник, 17 ноября 2014 г., 5:04:53 UTC+2 пользователь Andreas 
>>> Ka написал:

 thanks for your answer.

 yes, I just tried that. Same result.

>>>  
>>
>>> By now, I have understood much more about the templates.

>>>  
>>
>>> But still, for the admin pages
 mysite/templates/admin/base_site.html   
 doesn't work yet.


 ...

>>>
>> On Sun, Nov 16, 2014 at 7:19 PM, RLF_UNIQUE 
>>  wrote:
>>
>>> Obviously you've restarted the server and refreshed the page in such 
>>> a way to ensure it's not a caching issue ?
>>
>>
>>
>>> Check your settings file, are there two TEMPLATE_DIRS variables defined? 
>>> Possibly you created one in your edit, but Django already has an empty one 
>>> defined. If your edit was placed before the one that is already defined, it 
>>> woul

Re: Meta inheritance across abstract base class

[Torsten Bronger]

Hallöchen!

Collin Anderson writes:

> If you define a new class Meta on C, then it will _replace_ the
> previous class Meta. [...]

I indeed have a Meta class in C but it is derived from the upstream
Meta class.  The inheritance chain in my Meta's is uninterrupted.

Tschö,
Torsten.

-- 
Torsten BrongerJabber ID: torsten.bron...@jabber.rwth-aachen.de
  or http://bronger-jmp.appspot.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 http://groups.google.com/group/django-users.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-users/878uizqs1j.fsf%40physik.rwth-aachen.de.
For more options, visit https://groups.google.com/d/optout.

Re: Meta inheritance across abstract base class

[Collin Anderson]

Hi,

If you define a new class Meta on C, then it will _replace_ the previous 
class Meta. You can, however have class Meta inherit other class Meta.
class Student(CommonInfo):
# ...
class Meta(CommonInfo.Meta):
db_table = 'student_info'

https://docs.djangoproject.com/en/dev/topics/db/models/#meta-inheritance

Collin


On Monday, November 24, 2014 8:19:50 AM UTC-5, Torsten Bronger wrote:
>
> Hallöchen! 
>
> I have the following model structure: 
>
> class A(models.Model): 
> ... 
> class Meta: 
> ordering = ["timestamp"] 
> get_latest_by = "timestamp" 
>
> class B(A): 
> class Meta(A.Meta): 
> abstract = True 
>
> class C(B): 
> ... 
>
> Then, class C doesn't haven ordering or get_latest_by set.  Is this 
> expected behaviour?  Then, I would simply re-define them in B. 
>
> Tschö, 
> Torsten. 
>
> -- 
> Torsten BrongerJabber ID: torsten...@jabber.rwth-aachen.de 
>  
>   or http://bronger-jmp.appspot.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 http://groups.google.com/group/django-users.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-users/ae594b2d-caba-4e4a-91ba-f840bf9f5781%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Unable to open URL in new tab from ajax hit

[Collin Anderson]

Hi,

Are you doing cross-domain ajax, or is this all within one site?

Does this work?
def generate_birt(request):
url = 
'/birt/frameset?__report=report/test.rptdesign&sample=my+parameter&__format=pdf'
return  HttpResponseRedirect(url,mimetype='pdf')

Collin

On Monday, November 24, 2014 8:18:22 AM UTC-5, swapnil srivastava wrote:
>
> Ext.Ajax.request({
> url: 'generate_birt/',
> });
>
> in view.py 
>
>
> def generate_birt(request):
> url = '
> http://10.2.114.2:8080/birt/frameset?__report=report/test.rptdesign&sample=my+parameter&__format=pdf
> '
> return  HttpResponseRedirect(url,mimetype='pdf')
>
> following error throws  
>
>
> XMLHttpRequest cannot load 
> http://10.2.114.2:8080/birt/frameset?__report=report/test.rptdesign&sample=my+parameter&__format=pdf.
>  
> No 'Access-Control-Allow-Origin' header is present on the requested 
> resource. Origin 'http://10.2.114.2:8000' is therefor
>

-- 
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/f4b5274d-9171-49ac-9c26-5c4392979734%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Auto-refresh the webpage in the browser, after modify and save

[Collin Anderson]

Hi,

The one I've heard of the most is http://livereload.com/. There are other 
browser plugins too.

You could also check out "workspaces" in chrome for css at least.
https://developer.chrome.com/devtools/docs/workspaces

Collin


On Sunday, November 23, 2014 8:23:56 PM UTC-5, Jose Regalado wrote:
>
> Greetings...
>
> I need auto-refresh the webpage in the  browser, after modify and save any 
> file of my project, views: , css, jss, .*py, etc. I have 2 monitors. 
>
>  Exist some module or similar for django?, I am using 1.7 1.8-dev
>
> 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/9fa019ad-a7f5-4684-a003-42ae3981adae%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: my mysite/templates/admin/base_site.html is ignored (tutorial unclear?)

[Collin Anderson]

Hi,

Wow. Everything you've shown looks right.

Here's something to try: replace base_site.html with a completely empty 
file. That should cause the admin page to be completely blank.

If that works, could you post a snippet of where you're changing the 
template? Are you changing the  and expecting the  to be 
different?

Collin


On Saturday, November 22, 2014 8:05:30 PM UTC-5, Andreas Ka wrote:
>
> Thanks for your help.
>
> I really think there is something wrong with that part of the tutorial. A 
> small thing, but wrong.
>
>
> > Check your settings file, 
> > are there two TEMPLATE_DIRS variables defined?
>
> Nope. 
>
>
> This is where I placed it:
>
> ...
> import os
> BASE_DIR = os.path.dirname(os.path.dirname(__file__))
> TEMPLATE_DIRS = [os.path.join(BASE_DIR, 'templates')]
> ...
>
>
> just tried this:
>
> import mysite.settings as settings
> print settings.TEMPLATE_DIRS
> ['D:\\Programming\\eclipse\\mysite\\templates']
>
> so no: not empty.
>
>
> Why is my file templates/admin/base_site.html never called
> when I open http://127.0.0.1:8000/admin/ or 
> http://127.0.0.1:8000/admin/polls/  ?
>
>
> Thanks.
>
>
> On Fri, Nov 21, 2014 at 11:08 PM, donarb > 
> wrote:
>
>> On Friday, November 21, 2014 10:59:19 AM UTC-8, Andreas Ka wrote:
>>>
>>> I don't know.
>>> How to test that?
>>>
>>>
>>>
>>> The things I have done were these:
>>> https://docs.djangoproject.com/en/1.7/intro/tutorial02/#
>>> customizing-your-project-s-templates
>>>
>>> mkdir templates
>>> mkdir templates/admin
>>> cp 
>>> /usr/local/lib/python2.7/dist-packages/django/contrib/admin/templates/admin/base_site.html
>>>  
>>> templates/admin/
>>>
>>> ls -l templates/admin/base_site.html
>>> -rw-r--r-- 1 user group 338 Nov 21 18:50 templates/admin/base_site.html
>>> (and www-data is member of that group)
>>>
>>> nano templates/admin/base_site.html   -> changed it to what I want to see
>>> nano mysite/settings.py  -->   TEMPLATE_DIRS = [os.path.join(BASE_DIR, 
>>> 'templates')]
>>>
>>> restarted the server.
>>>
>>> On Fri, Nov 21, 2014 at 3:24 AM, Collin Anderson  
>>> wrote:
>>>
 Hi,

 Do other templates work in that folder?

 Collin


 On Monday, November 17, 2014 4:12:27 PM UTC-5, Andreas Ka wrote:

>
> > Show your view code
> The tutorial did not create any view.py for the admin pages
>
>
>
> See https://docs.djangoproject.com/en/1.7/intro/tutorial02/#customize-
> the-admin-look-and-feel
>
> We copied from the Django source files these two into:
> /mysite/templates/admin/base_site.html
> and
> /mysite/templates/admin/index.html
>
>
>
> and in https://docs.djangoproject.com/en/1.7/intro/tutorial02/#c
> ustomize-the-admin-change-list
> edited:
>
>
> admin.py
>
> from django.contrib import admin
>
> # Register your models here.
>
> from django.contrib import admin
> from polls.models import Choice, Question
>
>
> class ChoiceInline(admin.TabularInline):
> model = Choice
> extra = 3
>
>
> class QuestionAdmin(admin.ModelAdmin):
> fieldsets = [
> (None,   {'fields': ['question_text']}),
> ('Date information', {'fields': ['pub_date'], 'classes': 
> ['collapse']}),
> ]
> inlines = [ChoiceInline]
> list_display = ('question_text', 'pub_date', 
> 'was_published_recently')
> list_filter = ['pub_date']
> search_fields = ['question_text']
>
> admin.site.register(Question, QuestionAdmin)
>
>
> ---
>
>
>
> On Mon, Nov 17, 2014 at 2:11 PM, Artie  wrote:
>
>> Are you sure about correct path to your templates in views?
>>
>> Show your view code
>>
>> понедельник, 17 ноября 2014 г., 5:04:53 UTC+2 пользователь Andreas Ka 
>> написал:
>>>
>>> thanks for your answer.
>>>
>>> yes, I just tried that. Same result.
>>>
>>  
>
>> By now, I have understood much more about the templates.
>>>
>>  
>
>> But still, for the admin pages
>>> mysite/templates/admin/base_site.html   
>>> doesn't work yet.
>>>
>>>
>>> ...
>>>
>>
> On Sun, Nov 16, 2014 at 7:19 PM, RLF_UNIQUE  wrote:
>
>> Obviously you've restarted the server and refreshed the page in such 
>> a way to ensure it's not a caching issue ?
>
>
>
>> Check your settings file, are there two TEMPLATE_DIRS variables defined? 
>> Possibly you created one in your edit, but Django already has an empty one 
>> defined. If your edit was placed before the one that is already defined, it 
>> would end up empty, hence no override. 
>>
>>
>

-- 
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

Re: is it worth going for version 1.6 for commertial project

[George Silva]

I'm using the new migrations system with a production system and it's been
great.

No complaint at all.

On Tue, Nov 25, 2014 at 11:24 AM, Collin Anderson 
wrote:

> Hi All,
>
> If it helps, at work we have upgraded all of our websites to django 1.7,
> and are only now starting to think about using migrations.
>
> It's totally possible to use 1.7 without migrations.
>
> It's also worth noting that although Django supports 1.6 for another 4-5
> months, that's only for security fixes and data-loss bugs, whereas 1.7 gets
> more bug fixes.
>
> Collin
>
>
> On Saturday, November 22, 2014 7:56:47 PM UTC-5, Thomas wrote:
>>
>>
>> On Nov 22, 2014, at 4:53 AM, Krishnakant Mane  wrote:
>>
>> > Hello all,
>> > I have been looking for some good discussion on this issue.
>> > i see there is not much difference between 1.7 and 1.6 as far as my
>> requirement goes.
>> > I have gone through the official docs for both in a kind of rappid
>> specific way.
>> > As it is I am not going to use ORM at all.
>>
>> I am sticking with 1.6.x in case the new migration system needs a bit of
>> extra time to iron out.
>>
>> But since you are not using the ORM then you will not notice one way or
>> the other. I’d probably go with 1.7.x…
>>
>> 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/512ad969-af3b-445f-954c-b669674181f4%40googlegroups.com
> 
> .
>
> For more options, visit https://groups.google.com/d/optout.
>



-- 
George R. C. Silva
SIGMA Consultoria

http://www.consultoriasigma.com.br/

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

Re: is it worth going for version 1.6 for commertial project

[Collin Anderson]

Hi All,

If it helps, at work we have upgraded all of our websites to django 1.7, 
and are only now starting to think about using migrations.

It's totally possible to use 1.7 without migrations.

It's also worth noting that although Django supports 1.6 for another 4-5 
months, that's only for security fixes and data-loss bugs, whereas 1.7 gets 
more bug fixes.

Collin


On Saturday, November 22, 2014 7:56:47 PM UTC-5, Thomas wrote:
>
>
> On Nov 22, 2014, at 4:53 AM, Krishnakant Mane  > wrote: 
>
> > Hello all, 
> > I have been looking for some good discussion on this issue. 
> > i see there is not much difference between 1.7 and 1.6 as far as my 
> requirement goes. 
> > I have gone through the official docs for both in a kind of rappid 
> specific way. 
> > As it is I am not going to use ORM at all. 
>
> I am sticking with 1.6.x in case the new migration system needs a bit of 
> extra time to iron out. 
>
> But since you are not using the ORM then you will not notice one way or 
> the other. I’d probably go with 1.7.x… 
>
> 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/512ad969-af3b-445f-954c-b669674181f4%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Is it wrong to disable a lot of the core django features?

[Collin Anderson]

Hi all,

I agree that it's perfectly fine to not use the built in auth and admin 
apps, and people do it all the time. But, I wanted to give a quick proof of 
concept of using the admin with custom permissions.

# models.py
from django.contrib.auth.models import AbstractBaseUser
from django.db import models

class Company(models.Model):
name = models.CharField(max_length=255)

class Authority(models.Model):  # Permission
company = models.ForeignKey(Company)
name = models.CharField(max_length=255)

class Role(models.Model):  # Group
name = models.CharField(max_length=255)
authorities = models.ManyToManyField(Authority, blank=True)

class EmailUserManager(models.Manager):
def get_by_natural_key(self, email):
return self.get(email=email)

class CustomUser(AbstractBaseUser):
company = models.ForeignKey(Company)
email = models.EmailField('Email', unique=True)
roles = models.ManyToManyField(Role, related_name='users', blank=True)
USERNAME_FIELD = 'email'
REQUIRED_FIELDS = ['company']
is_staff = True  # all users can login to the admin
objects = EmailUserManager()

def get_short_name(self):
return self.email

@property
def authorities(self):
return Authority.objects.filter(role__users=self)


# admin.py
from django.contrib.auth.models import Group
from django.contrib import admin
from .models import Company, Role, Authority, CustomUser
admin.site.unregister(Group)

class PermAdmin(admin.ModelAdmin):

def has_add_permission(self, request):
permission_name = 'can_add_%s' % self.model._meta.model_name
return request.user.authorities.filter(name=permission_name).exists
()

def has_change_permission(self, request, obj=None):
permission_name = 'can_change_%s' % self.model._meta.model_name
return request.user.authorities.filter(name=permission_name).exists
()

def has_delete_permission(self, request, obj=None):
permission_name = 'can_delete_%s' % self.model._meta.model_name
return request.user.authorities.filter(name=permission_name).exists
()

def has_module_permission(self, request):
add = 'can_add_%s' % self.model._meta.model_name
change = 'can_change_%s' % self.model._meta.model_name
delete = 'can_delete_%s' % self.model._meta.model_name
return request.user.authorities.filter(name__in=(add, change, delete
)).exists()

admin.site.register(Role, PermAdmin)
admin.site.register(Company, PermAdmin)
admin.site.register(Authority, PermAdmin)
admin.site.register(CustomUser, PermAdmin)

Or it may be better to do the permission checking in user.has_perm() which 
the default has_change_permission() will call.

Collin

On Saturday, November 22, 2014 3:11:13 PM UTC-5, John Rodkey wrote:
>
> Gabriel,
>
> How would you store groups for each company within the default "groups" 
> database?  Our current database design is
>
> Company
> CustomUser belongs to Company
> Roles belongs to Company (replacing default "Groups" with "Roles")
> Roles has many Authorities (replacing default "Permissions" with 
> "Authorities")
> *additional tables will be configured for assigning Roles to CustomUsers 
> most likely through a many to many - join
>
> Using our very limited design above, what would you recommend approach be 
> for using the providing "Grouping/Perms"?
>
> On Saturday, November 22, 2014 3:58:17 AM UTC-6, Gabriel - Iulian Dumbrava 
> wrote:
>>
>> Hello!
>>
>> I would suggest to not drop the use of the built in auth module. You have 
>> many template and view tags, decorators, etc which are very helpful.
>>
>> You may, for example create a group for each company/branch then add each 
>> user to their respective groups upon registration.
>>
>> Each groups may have custom permissions, so you are not stuck with the 
>> built in add/edit/delete rights. You may create any type of permission and 
>> check for it in verious places.
>>
>> vineri, 21 noiembrie 2014, 22:18:27 UTC+2, John Rodkey a scris:
>>>
>>> We are evaluating django for a new internal CRM project and have issues 
>>> using many of the built in features including: the base user, permissions, 
>>> and authentication.
>>>
>>> We do not wish to use the built-in admin...  The level of complexity for 
>>> our permissions will be based on the employees job function/role.  While 
>>> django does offer "Groups" under permissions, we have many subsidiaries 
>>> which may name their own groups, this is our reasoning for dumping the 
>>> built-in permissions.
>>>
>>> What we are trying to accomplish -
>>>
>>> 1. User registration and authorization based on users email address. (We 
>>> believe this could be created with the "Custom User" information found in 
>>> the docs.)
>>>
>>> 2. Depending on the users email domain (the subsidiary) they work for, 
>>> they will only have access to that data (We do not believe django offers 
>>> this, and will be building it)
>>>
>>> 3. Each company (subsidiary) will

Re: DecimalField returns 'This value must be a decimal number' when blank

[elcaiaimar]

It works! You are great Collin! Thank you very much!

El domingo, 16 de noviembre de 2014 18:51:43 UTC+1, elcaiaimar escribió:
>
> Hello everybody, I've a problem with DecimalField at Forms. I've a long 
> form in my template and I want to left some fields in blank. I've declared 
> these fields with 
> *required=False*, but when I submit the form I receive this error: '*This 
> value must be a decimal number*'.
>
> I've tried to declare *blank=True, null=True* in respective fields in 
> models.py and make a syncdb but it continues without works
>
> Does somebody know how could I solve this problem?
>
> Thank you very much!
>

-- 
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/fb25d052-5d45-4e17-8cbf-e16dbe272988%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: redirect or reload page after pdf file generation.

[bo liu]

Hi, jai,
 Do you resolve this it? I have the same issue right now. Could you 
share your solution? thanks a lot.

Bo

On Wednesday, November 4, 2009 8:43:12 AM UTC-8, jai_python wrote:
>
> I save the response content in pdf file and then page will be 
> redirected and pdf file will be called on page onload 
>
> Thanks 
> Jai 
>
> On Nov 3, 11:10 am, Jani Tiainen  wrote: 
> > jai_python kirjoitti: 
> > 
> > 
> > 
> > > Hello every one, 
> > 
> > > I have a form which contains group of data and I can select some of 
> > > them to take pdf file.  When I submit the form, it returns pdf file 
> > > which contains the selected data. But i need to redirect or reload the 
> > > present form after pdf file has been generated inorder to remove 
> > > previous entry(i.e data included in the pdf file ) . Here goes my 
> > > source 
> > 
> > > def getPDF(request): 
> > >   if not request.POST: 
> > >return to html form page 
> > >   response = HttpResponse(mimetype='application/pdf') 
> > >   #some content will be added to response with the use REPORTLAB 
> > >   return response# will return pdf 
> > 
> > > This response will sent an pdf file to client side. same time i want 
> > > to reload or refresh after pdf file generation. 
> > 
> > I don't think that such a mechanism exists in HTTP protocol so what 
> > you're asking might not be really possible. 
> > 
> > With little JS (ajax iframe download) you can achieve that kind of 
> > refresh like functionality. But it relies on ajax functionality. 
> > 
> > -- 
> > Jani Tiainen

-- 
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/9d1e590b-8e3a-412a-ae82-847efbd09f2d%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

metaclass on model class calling db.models.options method vs django 1.7

[Matthieu Rigal]

Hi guys,

I am using a metaclass to standardize how I link two classes, on Django 
1.6. This is done in order to have a generic way of connecting classes 
without having to know the name of the fields being linked.

Basically, I have in my metaclass '*post_new*' method to get the 'other' 
model, using *model._meta.get_field_by_name('item') *I use this afterward 
like following *add_lazy_relation(model, None, item_model, 
add_passthrough_fields) *

I add these PassThrough fields again getting the fields from the meta, 
overwriting the getter and the setter.

Upgrading to Django 1.7 is impossible with what I'm currently doing. I get 
tons of *AppRegistryNotReady* , since it is going through this post_new 
method at the very beginning. 

Maybe you have a suggestion how I could get around this or which other 
methods to call to call later (but not too late, those are metaclasses) in 
order to get the list of fields. Maybe some code snippets running on Django 
1.7 and using models with metaclasses could already help.

Thanks in advance,
Matthieu

PS: I know it is a bit uncommon to do so and if you don't need to do so and 
use these metaclasses, you shouldn't ;-)

-- 
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/edfa1f75-212e-41a0-b3c2-6ddcb125efc1%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.