Enable admin log display to be restricted to a specific site

[Christopher Lenz <cmlenz@…>]

The admin log currently only provides way to show changes across all sites. For a project with multiple sites, it'd be very nice to be able to tell the admin log template tag to only show changes to objects that either aren't associated with any site, or associated with the current (or some other specific) site.

This requires the django_admin_log table to be extended with a nullable site_id column, which would require appropriate upgrade instructions ala:

BEGIN;
ALTER TABLE django_admin_log
  ADD site_id integer NULL REFERENCES django_site (id);
COMMIT;

The patch adds a method called get_for_obj to the SiteManager class, which attempts to find the site a given object is related with (either through a many-to-many, or a many-to-one relation). This function is reused in the django.views.defaults.shortcut function, which needs the same thing.

[Christopher Lenz <cmlenz@…>]

Patch as described above

[Christopher Lenz <cmlenz@…>]

Fixed patch, previous one didn't correctly filter the template tag output

[Jacob]

This is a good patch, and the get_for_site() method is a great idea. We probably should wait to apply this until before an actual release to avoid model breakage midstream, though... I'm not sure what our policy is on handling things like that.

[Simon G. <dev@…>]

Marked as Ready-for-checkin, given Jacob's comment above, and now (prior to 1.0) is probably the best time to do it.

[Malcolm Tredinnick]

Replying to jacob:

This is a good patch, and the get_for_site() method is a great idea. We probably should wait to apply this until before an actual release to avoid model breakage midstream, though... I'm not sure what our policy is on handling things like that.

Don't you mean *just after* an actual release? Otherwise everybody who has been following svn leading up to the release gets bonus code breakage on the day of the release (or just before). If we make a backwards-compat change the day after a release, it will mean that people can stabilise on the released version until they feel like making the changes, without fear of missing any intermediate bug fixes (which is the argument against doing it months after a release).

[Malcolm Tredinnick]

We're not making any more changes to existing admin, since it has limited lifespan. So the patch needs to be update for newforms-admin and applied whenever the maintainers of that branch can handle the backwards incompatibility (when newforms-admin is merged to trunk, all code using existing admin needs changing anyway, so this becomes part of that).

[Brian Rosner]

This functionality isn't critical to the merging of newforms-admin with trunk. Tagging with nfa-someday so it can be looked later.

[Aymeric Augustin]

Change UI/UX from NULL to False.

[Aymeric Augustin]

Change Easy pickings from NULL to False.