X-Forwarded-Prefix
Hi, I've been looking at the current support for X-Forwarded headers (cf. https://code.djangoproject.com/ticket/30729 or https://code.djangoproject.com/ticket/31354 for example). Is there any plan to deal with *X-Forwarded-Prefix*? Or is that header not std enough? If not, I'm not sure what would be the best / usual way for a user to customize HttpRequest (get_raw_uri, build_absolute_uri) to deal with it. Thanks, Marc -- You received this message because you are subscribed to the Google Groups "Django developers (Contributions to Django itself)" group. To unsubscribe from this group and stop receiving emails from it, send an email to django-developers+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/541333bb-9238-46ae-bea4-cbe28d3dce42n%40googlegroups.com.
Multiple instances of DjangoAdmin share the same model LogEntry
If someone uses two or more instances of the Django Admin interface, the sidebar on the right containing the "Recent actions", shares the same information for all instances of the Django Admin interface. This is because the model LogEntry is a singleton and shared across all instances of the Django Admin interface. As a consequence this may be confusing to some users, since they might expect that the log entries are bound to the current user interface. I had a look at the code and although it is possible to create separate entries for those logs, this is really complicated and requires a lot of work. Therefore I wanted to ask, if it would make sense to allow each instance of a Django Admin to specify its own model used to log entries? The default would of course be to fall back on the current behaviour. I have some ideas on how to achieve this. An instantiation of a Django Admin could specify its own model similar to LogEntry which itself should inherit from a class named AbstractLogEntry (which doesn't yet exist). This would also allow integrators to extend this class with additional columns for extra log entries. – Jacob -- You received this message because you are subscribed to the Google Groups "Django developers (Contributions to Django itself)" group. To unsubscribe from this group and stop receiving emails from it, send an email to django-developers+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/38c055d3-58ef-4a73-9784-be6877e31b2cn%40googlegroups.com.
Re: Proposal for an "Age" PostgreSQL ORM function
Am 21.01.23 um 10:53 schrieb 'Adam Johnson' via Django developers (Contributions to Django itself): A Django wrapper would actually be more complicated. You’d need to understand both the PostgreSQL and Django function docs, and you might not be sure Django does anything special besides call the SQL function. Well since this was posted in dev mailing list, thats exactly my argument - if datetime range calculations like done with AGE is seen as useful in general, it should be done for all db vendors. But thats much more involved and prolly needs as_db_xy() overloads with correct type coersion, so not so easy to extend on individual project basis (except for postgres, where it is 2 lines away). -- You received this message because you are subscribed to the Google Groups "Django developers (Contributions to Django itself)" group. To unsubscribe from this group and stop receiving emails from it, send an email to django-developers+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/ae05c31f-a5e3-385d-cc1a-71b888123fee%40netzkolchose.de.
