#18620 closed Cleanup/optimization (fixed)
Prefer current Site when checking M2M in "shortcut"/"view_on_site" redirect
Reported by: | Mike Tigas | Owned by: | Paulo |
---|---|---|---|
Component: | contrib.contenttypes | Version: | 1.4 |
Severity: | Normal | Keywords: | |
Cc: | Triage Stage: | Ready for checkin | |
Has patch: | yes | Needs documentation: | no |
Needs tests: | no | Patch needs improvement: | no |
Easy pickings: | no | UI/UX: | no |
Description
Given an object with a many-to-many relationship to django.contrib.sites.models.Site
, the django.contrib.contenttypes.views.shortcut
view simply picks the first domain returned, basically obj.<field>[0].domain
. (https://github.com/django/django/blob/4a103086/django/contrib/contenttypes/views.py#L45 -- it even notes that the ordering is arbitrary.)
This can be confusing when operating several (shared database) Django sites where sometimes content is cross-posted between said sites.
Example that led to my noticing this issue: A story being edited on www.spokesman.com but posted to sites [www.spokesman.com, www.downtoearthnw.com] redirects you to story's representation on the latter website when clicking "view on site" in the admin (or using anything else that uses that underlying shortcut
view). (Ostensibly because "www.downtoearthnw.com" sorts before "www.spokesman.com" and is therefore picked by the simple code I linked above.) Although this is a theoretically acceptable thing to happen, it's confusing to (even technical) users because they're on one of the acceptable sites for the content object and do not expect to be redirected to another site.
I propose that the view should prefer the current site in the event that both of the following are true:
a) the content object "Site" field is an M2M
b) the current Site object is one of the values set in that M2M
This shouldn't change behavior in any other circumstance (current site not in that M2M, site field is not M2M, etc), but it should alleviate some confusion to this specific usecase.
Have code and will post in a GitHub fork shortly.
Change History (12)
comment:1 by , 12 years ago
Triage Stage: | Unreviewed → Accepted |
---|
comment:2 by , 12 years ago
Has patch: | set |
---|
Fork: https://github.com/mtigas/django/tree/patches/ticket-18620
Pull request: https://github.com/django/django/pull/203
Test isn't the best but does fail without the views.py patch / tests the behavior pretty well.
comment:3 by , 12 years ago
Also I'm on the fence as to whether or not it should optimize and not query for current_site
until absolutely necessary (i.e. use lazy
or use some if-blocks). Basically to avoid one unnecessary query in the situation if we have a site FK.
comment:4 by , 10 years ago
Patch needs improvement: | set |
---|
comment:5 by , 7 years ago
Owner: | changed from | to
---|---|
Status: | new → assigned |
comment:6 by , 7 years ago
Patch needs improvement: | unset |
---|
comment:7 by , 7 years ago
Triage Stage: | Accepted → Ready for checkin |
---|
comment:8 by , 7 years ago
Patch needs improvement: | set |
---|---|
Triage Stage: | Ready for checkin → Accepted |
comment:9 by , 6 years ago
Patch needs improvement: | unset |
---|
comment:10 by , 6 years ago
Triage Stage: | Accepted → Ready for checkin |
---|
This makes sense and is backwards compatible.