et/11019andhttp://code.djangoproject.com/ticket/10761.
Aha, interesting... Thanks for the links.
E
>
> On May 22, 10:24 am, Eric Abrahamsen wrote:
>
>
>
> > I've got a Model A with a foreignkey to Model B, which is limited to
> > certain instances of Model B using limit_choices_to i
, Eric Abrahamsen wrote:
> I've got a Model A with a foreignkey to Model B, which is limited to
> certain instances of Model B using limit_choices_to in the foreign
> key. If I set up the admin so that Model A instances are editable
> inline through Model B instances, all Model
I've got a Model A with a foreignkey to Model B, which is limited to
certain instances of Model B using limit_choices_to in the foreign
key. If I set up the admin so that Model A instances are editable
inline through Model B instances, all Model B instance change forms
get forms for Mo
I found this patch (http://code.djangoproject.com/ticket/3096), but it
´s not working.
is anybody working on this issue?
thanks,
patrick
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To
I totally agree, I think it was a great idea and I am glad to help in
implementing it!
William: if you don't have edit_inline objects that need this functionality,
you should try my patch. I'd love to hear some feedback! :)
It makes it super easy to do something that no admin can be without: IE t
On Fri, Nov 23, 2007 at 02:05:28PM -0800, Dmitri Fedortchenko wrote:
>
> I found this ticket:
> http://code.djangoproject.com/ticket/2445
>
> It's not seen much activity for a while, but in september jkocherhans
> posted some news which I found interesting. So since I needed this
> functionality
display or otherwise
fetch the choices for this particular row.
The patch also allows you to use normal QuerySets with the choices=
attribute for a any field (so you don't need to use the function if
the choices are more or less static).
Basically this eliminates the need for limit_choices_to
I'd love to see this as well.
An alternative is to only show values that are actually in use for the
field in the list_filter. This would further reduce the clutter of
filters.
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Goo
Hi,
When I limit the choices in a one-to-many field with
"limit_choices_to", then the "list_filter" in the admin interface
should show the same limited choices. Does anyone disagree with this?
Else I file a feature requ
Hi all,
I saw many posts on this list on the dynamic limit_choices_to but I
think my
question is a little bit different, but very common as well.
Here is a very simple example. I'd like to filter the streets in the
DrugStore edit page so that only the streets in the sel
On 7/29/06, Michael Hamilton <[EMAIL PROTECTED]> wrote:
I've raised Ticket 2445 and attached a small patch - it sounds similar toTicket 2193, but 2193 might be intended to be even more general (not justvalues).Looks like a duplicate to me - I've marked #2193 as such (patch trumps empty ticket).
Th
I've raised Ticket 2445 and attached a small patch - it sounds similar to
Ticket 2193, but 2193 might be intended to be even more general (not just
values).
http://code.djangoproject.com/ticket/2445
http://code.djangoproject.com/ticket/2193
--~--~-~--~~~---~--~---
>
> This seems like a neat addition to Django - as long as no one can
> spot any potential problems.
Thanks, my python is a bit rusty.
The main concern I had with my suggestion was that it may encourage
developers to hook non-model specific behaviour into their models. At the
moment lim
On 27 Jul 2006, at 07:07, [EMAIL PROTECTED] wrote:
> So the db/models/query.py parse_lookup() expansion loop would include:
>
> if type(value) == types.FunctionType:
> value = value()
>
> I've tested such a change on Django 0.95 - it seems to work OK.
A neater way of
ould allow model definitions such as:
class TimeRecord(models.Model):
start_time = models.DateTimeField()
end_time= models.DateTimeField()
user= models.ForeignKey(User)
task= models.ForeignKey(Task,
limit_choices_to = {
Hi Matthew,
On Tue, 2006-07-18 at 13:31 +1000, Matthew Flanagan wrote:
> Hi,
>
> This ticket #1891 [1] has been outstanding for quite a while. I'm in
> the process of rolling out a large application that would really
> benefit from this being fixed. Is anyone able to look at it?
>
> Malcolm, di
Hi,
This ticket #1891 [1] has been outstanding for quite a while. I'm in
the process of rolling out a large application that would really
benefit from this being fixed. Is anyone able to look at it?
Malcolm, did you ever get around to proving your idea in your last
comment in the ticket?
[1] h
On Thursday 06 April 2006 17:38, Michael Radziej wrote:
> Hi,
>
> About magic-removal--I have defined a ForeignKey? with
> limit_choices_to for, say, "somefield". Now, when I do:
>
> someobject.somefield
>
> the resulting query to the related object does not use
Hi,
About magic-removal--I have defined a ForeignKey? with limit_choices_to
for, say, "somefield". Now, when I do:
someobject.somefield
the resulting query to the related object does not use this limitation.
Shouldn't it do this? Hmm, this is a "how is it supposed to wor
I used it on several examples and in each case it worked.
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com
To unsubsc
Your patch seems to be work.
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com
To unsubscribe from this group, send em
limit_choices_to is broken in m-r, it seems. The attached patch fixes
it I think, but as I don't know as much about this as I'd like and it's
1.00am here, I'm not going to commit it.
It seems that limit_choices_to is currently an attribute on the Options
class (aka Me
22 matches
Mail list logo
