Adding "reason" to django.shortcuts.redirect

[Skrattoune]

Hi,

I've recently discovered the possibility to add a `reason` to a redirect.

It's extremely useful for testing or debugging when a redirect to a same page can have different causes.

I'm proposing to add this functionality to `django.shortcuts.redirect` :

def redirect(to, *args, reason=None, permanent=False, **kwargs):

    """

    Return an HttpResponseRedirect to the appropriate URL for the arguments

    passed.

    The arguments could be:

        * A model: the model's `get_absolute_url()` function will be called.

        * A view name, possibly with arguments: `urls.reverse()` will be used

          to reverse-resolve the name.

        * A URL, which will be used as-is for the redirect location.

    Issues a temporary redirect by default; pass permanent=True to issue a

    permanent redirect.

    a redirect reason can be specified using the `reason` optional parameter

    """

    redirect_class = HttpResponsePermanentRedirect if permanent else HttpResponseRedirect

    return redirect_class(resolve_url(to, *args, **kwargs), reason=reason)

It does not affect any previous implementation.

only impact could be if somebody has decided to pass on to a specific page the kwarg `reason`

which is extremely minimal risk, and should be anyway easily detected through already present testing

Do I have go ahead to propose a PR?

[Adam Johnson]

This sounds reasonable, but unfortunately, it's backwards incompatible and so we cannot make the change. Any URL with a “reason” URL parameter would no longer be resolvable.

You can make a project-specific shortcut function that allows providing the reason parameter. Since it’s two lines long, it’s not a huge burden to add.

--
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-develop...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/71d5d7a0-da83-468b-8abb-96478fdcc0e4n%40googlegroups.com.

[Lily Foote]

> it's backwards incompatible and so we cannot make the change. Any URL with a “reason” URL parameter would no longer be resolvable.

I think if we decided this feature was sufficiently worthwhile, we could find a way to overcome the backward compatibility problem (a deprecation cycle, with perhaps a temporary setting or a new function with the extra functionality).

That said, I'm not clear on what the potential benefits of this change actually are, and I suspect they don't reach the high barrier to justify the extra hassle here.

Sent with Proton Mail secure email.

------- Original Message -------

To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/CAMyDDM2PNsHB3OOxS18MJQncN0NkQu-bdYE8Pua%2BhazgOemp4Q%40mail.gmail.com.

[Skrattoune]

It is already implemented in my projects.

So far, my main use cases are for the testing of views or their debugging.

When several reasons can lead to a redirect to the same address or view, it allows me to ensure that the redirect is because of the reason I'm expecting.

I think it's a good tool.

If there is no will to "break" the full retro compatibility, maybe an additional shortcut can be provided to django users if power-users see an added value in it.

If not ... that will stay as an internal practice of mine