I was implying that if I'm in email admin, and there's filters there,
once I leave email admin, there's no reason to keep that information
around. Going back to the email admin should give a clean start,
that's how typical applications like that work (at least every one
that I've ever used).
But
I wasn't thinking that the filters would be preserved across
*different* models or admin pages, only within them. So, you'd keep
some sort of dictionary, keyed based on the particular admin URL,
model, or some other easily achievable unique piece of information per
screen. I wouldn't exp
I guess you're right. This is just for admin so it's not a huge deal.
It will feel weird howerver, if I somehow go to a search results page
and it remembers my filters when I was visiting something else before
that. So it'd need to handle clearing it at the right time as well.
On Nov 11, 3:51 pm
Don't sessions already have standard expirations in them? Besides
that, this is the admin, it's not a tool for every user of your
application to be in, so there will only be a few larger sessions (and
larger is still only a few K at most, if you have lots and lots of
models you're filteri
Well I'm not sure storing multiple search paths is too good of an
idea, as you increase the size of the session significantly, and then
have to worry about expiring those or clearing them somehow. The
session just keeps it for that users session, vs whoever else happens
to visit that url (say I pa
I definitely second this. The extra bonus to storing it in the
session is that you can maintain your search state on multiple admin
pages/models independently without overflowing the URL. Naturally if
you do it this way, you'd also want to have a visible "clear filters"
link so that ther
Before this gets accepted, I'd like to throw in the proposal of
storing this in the session vs a huge URL. That and a hash seem to be
the common approach to storing search paths.
On Nov 11, 7:19 am, Jonas Pfeil <[EMAIL PROTECTED]> wrote:
> Currently if you search in the admin, use some kind of fi
folks, hi,
i wonder if you could kindly include, if nothing else, the
pimentech.network classes, which can be downloaded from
http://lkcl.net/libcommonDjango.tgz in the contrib directory of django
or just as a standard django module.
they're important enough and small enough to be included in djan
This change is here because when you say "this foreign key is in
list_filter" it immediately does a select_related() (grabbing every single
relation which is ridiculous). This change says "only grab the foreign keys
which are used. The only addition is that list_select_related can be a
boolean, or
On Tue, Nov 11, 2008 at 5:02 AM, Daniel Roseman
<[EMAIL PROTECTED]> wrote:
>
> Sorry to bring this discussion back to the original topic...
>
> http://code.djangoproject.com/ticket/9498 is a pretty serious
> regression for us, which will prevent us upgrading to 1.0.1. There is
> a patch, and I've
Currently if you search in the admin, use some kind of filter or even
just go to the second page in the change list this selection is reset
when you edit an item and hit save. The user gets the default list
again. Needless to say this can be quite annoying. Especially if you
want to edit a specifi
Sorry to bring this discussion back to the original topic...
http://code.djangoproject.com/ticket/9498 is a pretty serious
regression for us, which will prevent us upgrading to 1.0.1. There is
a patch, and I've just added some tests - is there any chance this
will make it into the release?
Thank
On Mon, 2008-11-10 at 16:15 -0800, SmileyChris wrote:
> There are currently inconsistencies with how ModelAdmin decides on
> what query set (i.e. manager) it's using.
Caused by people abusing the notion of default manager and some
people wanting to accommodate that. :-(
> Issue 1: The change li
On Mon, 2008-11-10 at 17:13 -0800, David Cramer wrote:
[...]
> Anyways, what it does:
>
> * list_select_related can be a boolean, or a list. If it's a list it
> says "select_related on these fields"
How is that different functionality from just specifying the names of
the fields in the current
Hiya,
I thought I would shout out ticket #1848 (30 minute increments in the
admin time widget) for inclusion in 1.1, if anyone wants it. I'm still
using it and others might find it useful.
http://code.djangoproject.com/ticket/1848
-rob
--~--~-~--~~~---~--~~
You re
15 matches
Mail list logo
