Opened 3 years ago

Last modified 9 months ago

#18620 new Cleanup/optimization

Prefer current Site when checking M2M in "shortcut"/"view_on_site" redirect

Reported by: mtigas Owned by: nobody
Component: contrib.contenttypes Version: 1.4
Severity: Normal Keywords:
Cc: Triage Stage: Accepted
Has patch: yes Needs documentation: no
Needs tests: no Patch needs improvement: yes
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 (4)

comment:1 Changed 3 years ago by aaugustin

  • Needs documentation unset
  • Needs tests unset
  • Patch needs improvement unset
  • Triage Stage changed from Unreviewed to Accepted

This makes sense and is backwards compatible.

comment:2 Changed 3 years ago by mtigas

  • 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.

Version 0, edited 3 years ago by mtigas (next)

comment:3 Changed 3 years ago by mtigas

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 Changed 9 months ago by timo

  • Patch needs improvement set
Note: See TracTickets for help on using tickets.
Back to Top