> Your analysis is entirely correct, as far as I can tell. Setting
> attributes on `self` in a per-request method of a `ModelAdmin` is not
> concurrency-safe, and it should not be recommended or demonstrated in
> the docs. If you'd be willing to file a bug (or, better, a PR) to fix
> this documenta
https://github.com/django/django/blob/master/django/contrib/admin/sites.py#L104
> On Nov 12, 2014, at 1:36 PM, Collin Anderson wrote:
>
> On Tuesday, November 11, 2014 3:24:48 PM UTC-5, Peter Sagerson wrote:
> The documentation of ModelAdmin.get_form()[1] demonstrates modifying
> self
The documentation of ModelAdmin.get_form()[1] demonstrates modifying
self.exclude in order to modify the add/change form on a per-request basis.
However, looking at django.contrib.admin, it seems clear that ModelAdmin is
instantiated when it's installed, not for every request. It also doesn't
a
I imagine that would work. Generally speaking, if you want to use a multi-page
flow to atomically mutate some state (in this case auth status), you're pretty
much into form wizard territory. For specific scenarios, there may be
workarounds--potentially a bit sneaky and underhanded--that produce
st not
> dug into the gritty details of the system.
>
> Any tips on creating a 2 stage approach would be much appreciated.
>
> On Wednesday, July 3, 2013 1:34:31 PM UTC-7, Peter Sagerson wrote:
>>
>> I took part of this conversation offline to spare the list from the gory
27;s probably out of the scope of what you have right now. I'd
> still like like to see something that ties it up nicely. That's basically
> what I'm building right now except I don't trust my build to work in anyone
> else's setup - although if I have time I'll s
tion for Django
> but I don't think many people will know where to start when it comes to using
> it (myself included).
>
> On Wednesday, September 12, 2012 1:27:26 PM UTC-7, Peter Sagerson wrote:
> I recently released a suite of packages to support two-factor authentication
Assuming you're using Django 1.1, take a look at:
http://docs.djangoproject.com/en/1.1/topics/db/queries/#filters-can-reference-fields-on-the-model
On Dec 8, 2009, at 10:18 AM, pbzRPA wrote:
> Hi,
>
> I am not sure if this is a really stupid question but how can you
> filter a model by comparin
Yes, Django always cascades deletes. There's talk about providing more
options in a future release, but for now it's kind of a problem. I
generally find this behavior potentially catastrophic, so I wrote an
intermediate model base class that clears all nullable foreign keys
before deleting
Is request.path[1] what you want?
You might also consider basing your menu context on the current view
rather than the current URL. I typically define a view decorator that
can attach any context information I need to the current request:
def page_context(section):
def decorator(func):
The way I solved this was to write a custom auth backend that could
evaluate a collection of non-model permissions. By convention, I had
one permission per view. Some of these permissions were aliased to
corresponding model permissions and some of them were based on other
criteria. Essenti
11 matches
Mail list logo
