id	summary	reporter	owner	description	type	status	component	version	severity	resolution	keywords	cc	stage	has_patch	needs_docs	needs_tests	needs_better_patch	easy	ui_ux
24201	order_with_respect_to GenericForeignKey	Alex Hill	nobody	"As of 1.8, order_with_respect_to nearly works with generic relations.

First thing that's broken is the `get_RELATED_order` and `set_RELATED_order` methods. They are set in [[https://github.com/django/django/blob/d450af8a2687ca2e90a8790eb567f9a25ebce85b/django/db/models/base.py#L320|ModelBase._prepare]]. You don't know what model is going to be on the other end of the GenericForeignKey, so I think those can simply be omitted if `opts.order_with_respect_to.rel` is `None`. (Perhaps something can be done here in cases where a `GenericRelation` is defined.)

Next, you run into trouble [https://github.com/django/django/blob/d450af8a2687ca2e90a8790eb567f9a25ebce85b/django/db/models/base.py#L796 when Django tries to save a new object's _order field], because there's no `attname` attribute on the `GenericForeignKey`. You run into the same problem in `_get_next_or_previous_in_order()`.

This is easily solved if you're OK with sprinkling details of the GenericForeignKey implementation in Django core: you can just try `attname`, and if that fails, filter on GFK's `ct_field` and `pk_field`. But maybe a better idea would be to introduce a method on field-like things returning a dictionary of filter parameters matching a given object, or else a property returning a sequence of (filter name, attribute name) pairs from which the filter parameters can be constructed. In the latter case, regular fields would return `((self.name, self.attname),)`, and GFKs would return `((self.fk_field, self.fk_field), (self.ct_field, self.ct_field))`.

Here's a branch illustrating the necessary changes: https://github.com/AlexHill/django/compare/order_wrt_gfks"	New feature	closed	Database layer (models, ORM)		Normal	fixed			Ready for checkin	1	0	0	0	0	0