From 687343d43c70f9e55a558999ec4065a49323d2bf Mon Sep 17 00:00:00 2001 From: Karl Hobley Date: Mon, 11 Mar 2019 18:42:11 +0000 Subject: [PATCH 1/6] RFC 34: Redirects admin changes --- text/034-redirects-admin-changes.md | 51 +++++++++++++++++++++++++++++ 1 file changed, 51 insertions(+) create mode 100644 text/034-redirects-admin-changes.md diff --git a/text/034-redirects-admin-changes.md b/text/034-redirects-admin-changes.md new file mode 100644 index 00000000..9626c10f --- /dev/null +++ b/text/034-redirects-admin-changes.md @@ -0,0 +1,51 @@ +# RFC: Redirects admin changes + +# Adding new redirects automatically +## On page move + +We will add a new checkbox to the page move UI which asks the user if they would like to create a redirect from the old location to the new one. + +![](https://d2mxuefqeaa7sj.cloudfront.net/s_C6D086527C63F45E9EA73587C2533A89CBE7313C89FA1DC0882B73424CAB09BB_1552329395110_Screenshot_2019-03-11+Wagtail+-+Move+Blog1.png) + + +If they check this, and the page has subpages, they will be shown another checkbox asking them if they want to create recursive redirects for every descendant page. + +![](https://d2mxuefqeaa7sj.cloudfront.net/s_C6D086527C63F45E9EA73587C2533A89CBE7313C89FA1DC0882B73424CAB09BB_1552329038086_Screenshot_2019-03-11+Wagtail+-+Move+Blog2.png) + +## On page slug change + +When a page’s slug is changed, a checkbox will appear underneath the slug field asking the user if they would like to create a redirect from the old slug. + +If they check this box and their page has subpages, they will be given another checkbox asking them if they would like to create recursive redirects for every descendant page as well. + +## When unpublishing or deleting a page + +When unpublishing or deleting a page, the user can add a redirect from that page’s URL to another page. If they create one, they will be given the option to repoint existing redirects at the new page, delete the existing redirects, or (when not deleting) do nothing. + +## Deleting redirects when pages are created in their place + +Whenever a page is created, moved, or re-slugged in a way that causes it or one of its descendants to clash with a redirect. That or those redirects should be deleted. The user should always be given a warning if this is going to happen, with an option of overriding it if they want to keep them. + +# Redirect management +## Management from the page explorer interface +![](https://d2mxuefqeaa7sj.cloudfront.net/s_C6D086527C63F45E9EA73587C2533A89CBE7313C89FA1DC0882B73424CAB09BB_1552329309392_Screenshot_2019-03-11+Wagtail+-+Exploring+Welcome+to+the+Wagtail+Bakery+1.png) + + +We will add a “redirects” icon at the top right of the page explorer. This will indicate the number of redirects where their “from path” is from within this section. Clicking this will link the user to the redirect management which would be filtered to show only redirects from this section. This button will only be visible to users who have permission to manage redirects. + +We will also add a new “Add redirect here” button in the “more” menu. This takes the user to the add redirect UI with the prefix pre-filled (and undeletable). + +An alternative to this would be to create a “RedirectPage” type which is a page type that acts as a redirect when served, but these aren’t as flexible and are more heavier to handle in the database than redirects are. + +## Management of masked redirects + +Redirects are only used for requests that return a 404. So if a redirect exists for a URL that contains a page or is routable from Django, the redirect would be considered “masked”. + +Masked redirects may not be considered bad, but it might be useful to surface them in the admin interface and make them filterable. + +## Bulk actions + +Removing many redirects at once is quite tedious. This will be more of a problem when we start adding new ways to add redirects. + +We should improve the redirect search to allow filtering by prefix, and add a bulk delete action which can use checkboxes by each row or all redirects that match the current query. + From 987c425e20a02cbc4baaa3678cbeefd766576a5e Mon Sep 17 00:00:00 2001 From: Karl Hobley Date: Mon, 18 Mar 2019 11:43:43 +0000 Subject: [PATCH 2/6] Remove mention of "Masked redirects" For another time I think --- text/034-redirects-admin-changes.md | 6 ------ 1 file changed, 6 deletions(-) diff --git a/text/034-redirects-admin-changes.md b/text/034-redirects-admin-changes.md index 9626c10f..1b4ddaff 100644 --- a/text/034-redirects-admin-changes.md +++ b/text/034-redirects-admin-changes.md @@ -37,12 +37,6 @@ We will also add a new “Add redirect here” button in the “more” menu. Th An alternative to this would be to create a “RedirectPage” type which is a page type that acts as a redirect when served, but these aren’t as flexible and are more heavier to handle in the database than redirects are. -## Management of masked redirects - -Redirects are only used for requests that return a 404. So if a redirect exists for a URL that contains a page or is routable from Django, the redirect would be considered “masked”. - -Masked redirects may not be considered bad, but it might be useful to surface them in the admin interface and make them filterable. - ## Bulk actions Removing many redirects at once is quite tedious. This will be more of a problem when we start adding new ways to add redirects. From 1c1c41895691f5bb0626938bf11d560244b4e118 Mon Sep 17 00:00:00 2001 From: Karl Hobley Date: Mon, 18 Mar 2019 13:00:13 +0000 Subject: [PATCH 3/6] Add prefix redirects --- text/034-redirects-admin-changes.md | 87 +++++++++++++++++++++++------ 1 file changed, 71 insertions(+), 16 deletions(-) diff --git a/text/034-redirects-admin-changes.md b/text/034-redirects-admin-changes.md index 1b4ddaff..19c42aca 100644 --- a/text/034-redirects-admin-changes.md +++ b/text/034-redirects-admin-changes.md @@ -1,35 +1,72 @@ -# RFC: Redirects admin changes +# RFC: Redirects changes -# Adding new redirects automatically -## On page move +## Models changes -We will add a new checkbox to the page move UI which asks the user if they would like to create a redirect from the old location to the new one. +### Prefix redirects -![](https://d2mxuefqeaa7sj.cloudfront.net/s_C6D086527C63F45E9EA73587C2533A89CBE7313C89FA1DC0882B73424CAB09BB_1552329395110_Screenshot_2019-03-11+Wagtail+-+Move+Blog1.png) +We will add a new type of redirect that matches on prefixes rather than full URLs. The rest of the URL path that's not part of the redirect's ``old_path`` field will be appended to the destination path. + +For example, say we have the following prefix redirect: + + - ``/articles`` to ``/news`` + +When a user then requests, ``/articles/the-article/`` this will be matched by the prefix redirect and the user will be redirected to ``/news/the-article/``. + +To allow creating redirects of this type, a new "Match prefix" checkbox/boolean field will be added to redirects. + +#### Choosing the most specific redirect + +If multiple prefix redirects and/or a single redirect matches the same URL, the most specific redirect is used. +For example, say we have the following redirects: -If they check this, and the page has subpages, they will be shown another checkbox asking them if they want to create recursive redirects for every descendant page. + - prefix redirect from ``/articles`` to ``/news`` + - prefix redirect from ``/articles/events`` to ``/events`` + - direct redirect from ``/articles/events/christmas`` to ``/christmas`` -![](https://d2mxuefqeaa7sj.cloudfront.net/s_C6D086527C63F45E9EA73587C2533A89CBE7313C89FA1DC0882B73424CAB09BB_1552329038086_Screenshot_2019-03-11+Wagtail+-+Move+Blog2.png) +Requests will be redirected as follows: + + - ``/articles/events/christmas/`` to ``/christmas/`` + - ``/articles/events/other-event/`` to ``/events/other-event/`` + - ``/articles/the-article/`` to ``/news/the-article/`` + +## Admin changes + +### Adding new redirects automatically + +#### On page move + +We will add a new checkbox to the page move UI which asks the user if they would like to create a redirect from the old location to the new one. + +![](https://d2mxuefqeaa7sj.cloudfront.net/s_C6D086527C63F45E9EA73587C2533A89CBE7313C89FA1DC0882B73424CAB09BB_1552329395110_Screenshot_2019-03-11+Wagtail+-+Move+Blog1.png) -## On page slug change +If this is checked, a redirect to the page will be created from the previous URL of the page. If the page has any children, this redirect will be a prefix redirect. + +#### On page slug change When a page’s slug is changed, a checkbox will appear underneath the slug field asking the user if they would like to create a redirect from the old slug. -If they check this box and their page has subpages, they will be given another checkbox asking them if they would like to create recursive redirects for every descendant page as well. +If this is checked when the page is published with the new slug, a redirect to the page will be created from the previous URL of the page. If the page has any children, this redirect will be a prefix redirect. + +**Q: What if the page is saved as draft? The redirect cannot be created yet but the user who publishes it may not be aware that there is a checkbox on the promote tab.** -## When unpublishing or deleting a page +#### When unpublishing or deleting a page When unpublishing or deleting a page, the user can add a redirect from that page’s URL to another page. If they create one, they will be given the option to repoint existing redirects at the new page, delete the existing redirects, or (when not deleting) do nothing. -## Deleting redirects when pages are created in their place +#### Deleting redirects when pages are created in their place -Whenever a page is created, moved, or re-slugged in a way that causes it or one of its descendants to clash with a redirect. That or those redirects should be deleted. The user should always be given a warning if this is going to happen, with an option of overriding it if they want to keep them. +Whenever a page is created, moved, or re-slugged in a way that causes it, or one of its descendants to clash with a redirect. That or those redirects should be deleted. The user should always be given a warning if this is going to happen, with an option of overriding it if they want to keep them. -# Redirect management -## Management from the page explorer interface -![](https://d2mxuefqeaa7sj.cloudfront.net/s_C6D086527C63F45E9EA73587C2533A89CBE7313C89FA1DC0882B73424CAB09BB_1552329309392_Screenshot_2019-03-11+Wagtail+-+Exploring+Welcome+to+the+Wagtail+Bakery+1.png) +### Redirect management + +#### Searching for prefix redirects +The search will return any prefix redirect that matched the searched path. If multiple redirects match, the results will be displayed in order of specificity with most specific first. + +#### Management from the page explorer interface + +![](https://d2mxuefqeaa7sj.cloudfront.net/s_C6D086527C63F45E9EA73587C2533A89CBE7313C89FA1DC0882B73424CAB09BB_1552329309392_Screenshot_2019-03-11+Wagtail+-+Exploring+Welcome+to+the+Wagtail+Bakery+1.png) We will add a “redirects” icon at the top right of the page explorer. This will indicate the number of redirects where their “from path” is from within this section. Clicking this will link the user to the redirect management which would be filtered to show only redirects from this section. This button will only be visible to users who have permission to manage redirects. @@ -37,9 +74,27 @@ We will also add a new “Add redirect here” button in the “more” menu. Th An alternative to this would be to create a “RedirectPage” type which is a page type that acts as a redirect when served, but these aren’t as flexible and are more heavier to handle in the database than redirects are. -## Bulk actions +#### Bulk actions Removing many redirects at once is quite tedious. This will be more of a problem when we start adding new ways to add redirects. We should improve the redirect search to allow filtering by prefix, and add a bulk delete action which can use checkboxes by each row or all redirects that match the current query. +## Drawbacks + +### Redirect chains and loops + +It's possible with both prefix and direct redirects to create "redirect chains" where one redirect just leads to another redirect. These are much more likely to happen after we introduce the automatic creation of prefix redirects. For example: + +Say we have a section within a section: ``/articles/events`` + +If the user renames ``articles`` to ``news``, then moves ``events`` out into its own section, this will create two prefix redirects: + + - ``/articles`` to ``/news`` + - ``/news/events`` to ``/events`` + +A request to ``/articles/events/christmas/`` would be redirected to ``/news/events/christmas/`` then redirected again to ``/events/christmas/``. + +No attempt will be made to resolve redirect chains/loops on the server-side as this depends on the knowledge that the each step of the redirect chain will result in a 404. While we can figure out if a URL points to a Wagtail page, it's impossible to know for sure that the redirect URL will result in a 404, as there may be URLs configured in the web server that Wagtail does not know about. + +The same goes for redirect loops, we will rely on web browsers to limit the number of redirects the user receives to break out of any loops. From a7697f15cf425f4d3fd0f36009e99f02ef10a90b Mon Sep 17 00:00:00 2001 From: Karl Hobley Date: Mon, 18 Mar 2019 13:14:37 +0000 Subject: [PATCH 4/6] Remove section on deleting existing redirect I think this would be hard to implement --- text/034-redirects-admin-changes.md | 4 ---- 1 file changed, 4 deletions(-) diff --git a/text/034-redirects-admin-changes.md b/text/034-redirects-admin-changes.md index 19c42aca..26957bf7 100644 --- a/text/034-redirects-admin-changes.md +++ b/text/034-redirects-admin-changes.md @@ -54,10 +54,6 @@ If this is checked when the page is published with the new slug, a redirect to t When unpublishing or deleting a page, the user can add a redirect from that page’s URL to another page. If they create one, they will be given the option to repoint existing redirects at the new page, delete the existing redirects, or (when not deleting) do nothing. -#### Deleting redirects when pages are created in their place - -Whenever a page is created, moved, or re-slugged in a way that causes it, or one of its descendants to clash with a redirect. That or those redirects should be deleted. The user should always be given a warning if this is going to happen, with an option of overriding it if they want to keep them. - ### Redirect management #### Searching for prefix redirects From e585d7887041f915fb0ab160a4ff9c229343d281 Mon Sep 17 00:00:00 2001 From: Karl Hobley Date: Thu, 10 Jun 2021 16:54:31 +0100 Subject: [PATCH 5/6] Updated --- text/034-redirects-admin-changes.md | 91 ++++++----------------------- 1 file changed, 18 insertions(+), 73 deletions(-) diff --git a/text/034-redirects-admin-changes.md b/text/034-redirects-admin-changes.md index 26957bf7..eafc4c05 100644 --- a/text/034-redirects-admin-changes.md +++ b/text/034-redirects-admin-changes.md @@ -1,96 +1,41 @@ -# RFC: Redirects changes +# RFC 34: Automatic redirects -## Models changes +A commonly requested feature for Wagtail is automatically creating redirects to pages on certain events such as moving, changing slug, and deleting a page. -### Prefix redirects +This RFC contains a proposal to add this feature into Wagtail. -We will add a new type of redirect that matches on prefixes rather than full URLs. The rest of the URL path that's not part of the redirect's ``old_path`` field will be appended to the destination path. +## Motivation -For example, say we have the following prefix redirect: +Currently, if the user changes a page's slug, or moves a page, the URL of that page will be changed and any requests going to the previous URL may result in a 404. - - ``/articles`` to ``/news`` +This is a highly undesirable outcome as links to those pages would be broken, and it's to automatically correct this if we haven't recorded anywhere where that page went. The burden is on the end user to figure out where the content they are looking for has gone, but this can sometimes be difficult if they are unfamiliar with the site and it's unlikely they have the patience to do that. -When a user then requests, ``/articles/the-article/`` this will be matched by the prefix redirect and the user will be redirected to ``/news/the-article/``. +In order to prevent this from happening, editors must manually create redirects for pages that they move or change the slug of on their site, and repeat this for any child pages. This could be a tedious task and may be forgotten. -To allow creating redirects of this type, a new "Match prefix" checkbox/boolean field will be added to redirects. +This is a task that can be quite easily handled by Wagtail. We just need to add a user interface to allow a user to specify if they want redirects to be created on moving pages or changing slugs and Wagtail can do the rest of the work. -#### Choosing the most specific redirect +## Specification -If multiple prefix redirects and/or a single redirect matches the same URL, the most specific redirect is used. +We will implement automatic creation of redirects in the following places. Note that users must have permission to add redirects in order for any of these interfaces to appear. -For example, say we have the following redirects: - - - prefix redirect from ``/articles`` to ``/news`` - - prefix redirect from ``/articles/events`` to ``/events`` - - direct redirect from ``/articles/events/christmas`` to ``/christmas`` - -Requests will be redirected as follows: - - - ``/articles/events/christmas/`` to ``/christmas/`` - - ``/articles/events/other-event/`` to ``/events/other-event/`` - - ``/articles/the-article/`` to ``/news/the-article/`` - -## Admin changes - -### Adding new redirects automatically - -#### On page move +### On page move We will add a new checkbox to the page move UI which asks the user if they would like to create a redirect from the old location to the new one. ![](https://d2mxuefqeaa7sj.cloudfront.net/s_C6D086527C63F45E9EA73587C2533A89CBE7313C89FA1DC0882B73424CAB09BB_1552329395110_Screenshot_2019-03-11+Wagtail+-+Move+Blog1.png) -If this is checked, a redirect to the page will be created from the previous URL of the page. If the page has any children, this redirect will be a prefix redirect. +If this is checked, a redirect to the page will be created from the previous URL of the page. Redirects are also created for all descendants of the page. -#### On page slug change +### On page slug change When a page’s slug is changed, a checkbox will appear underneath the slug field asking the user if they would like to create a redirect from the old slug. -If this is checked when the page is published with the new slug, a redirect to the page will be created from the previous URL of the page. If the page has any children, this redirect will be a prefix redirect. - -**Q: What if the page is saved as draft? The redirect cannot be created yet but the user who publishes it may not be aware that there is a checkbox on the promote tab.** - -#### When unpublishing or deleting a page - -When unpublishing or deleting a page, the user can add a redirect from that page’s URL to another page. If they create one, they will be given the option to repoint existing redirects at the new page, delete the existing redirects, or (when not deleting) do nothing. - -### Redirect management - -#### Searching for prefix redirects - -The search will return any prefix redirect that matched the searched path. If multiple redirects match, the results will be displayed in order of specificity with most specific first. - -#### Management from the page explorer interface - -![](https://d2mxuefqeaa7sj.cloudfront.net/s_C6D086527C63F45E9EA73587C2533A89CBE7313C89FA1DC0882B73424CAB09BB_1552329309392_Screenshot_2019-03-11+Wagtail+-+Exploring+Welcome+to+the+Wagtail+Bakery+1.png) - -We will add a “redirects” icon at the top right of the page explorer. This will indicate the number of redirects where their “from path” is from within this section. Clicking this will link the user to the redirect management which would be filtered to show only redirects from this section. This button will only be visible to users who have permission to manage redirects. - -We will also add a new “Add redirect here” button in the “more” menu. This takes the user to the add redirect UI with the prefix pre-filled (and undeletable). - -An alternative to this would be to create a “RedirectPage” type which is a page type that acts as a redirect when served, but these aren’t as flexible and are more heavier to handle in the database than redirects are. - -#### Bulk actions - -Removing many redirects at once is quite tedious. This will be more of a problem when we start adding new ways to add redirects. - -We should improve the redirect search to allow filtering by prefix, and add a bulk delete action which can use checkboxes by each row or all redirects that match the current query. - -## Drawbacks - -### Redirect chains and loops - -It's possible with both prefix and direct redirects to create "redirect chains" where one redirect just leads to another redirect. These are much more likely to happen after we introduce the automatic creation of prefix redirects. For example: - -Say we have a section within a section: ``/articles/events`` - -If the user renames ``articles`` to ``news``, then moves ``events`` out into its own section, this will create two prefix redirects: +If this is checked, a redirect to the page will be created from the previous URL of the page. Redirects are also created for all descendants. - - ``/articles`` to ``/news`` - - ``/news/events`` to ``/events`` +Note that if the page is saved in draft, the redirects are still created but they won't take effect until the slug change is published since redirects only work if there is not already a page at the URL. -A request to ``/articles/events/christmas/`` would be redirected to ``/news/events/christmas/`` then redirected again to ``/events/christmas/``. +### When unpublishing or deleting a page -No attempt will be made to resolve redirect chains/loops on the server-side as this depends on the knowledge that the each step of the redirect chain will result in a 404. While we can figure out if a URL points to a Wagtail page, it's impossible to know for sure that the redirect URL will result in a 404, as there may be URLs configured in the web server that Wagtail does not know about. +When unpublishing or deleting a page or page tree, the user will be given the option to add redirects to a page. This will also update any existing redirects pointing at the page being deleted. -The same goes for redirect loops, we will rely on web browsers to limit the number of redirects the user receives to break out of any loops. +Note that if the user is deleting a page tree, the user will only be able to choose a single destination page for all the redirects that get created. From 9fb26d706e46eebe39adb21289fa6fa9bd32d809 Mon Sep 17 00:00:00 2001 From: Karl Hobley Date: Thu, 17 Jun 2021 16:07:19 +0100 Subject: [PATCH 6/6] Updated text --- text/034-redirects-admin-changes.md | 59 +++++++++++++++++++++-------- 1 file changed, 43 insertions(+), 16 deletions(-) diff --git a/text/034-redirects-admin-changes.md b/text/034-redirects-admin-changes.md index eafc4c05..161f335e 100644 --- a/text/034-redirects-admin-changes.md +++ b/text/034-redirects-admin-changes.md @@ -1,8 +1,6 @@ # RFC 34: Automatic redirects -A commonly requested feature for Wagtail is automatically creating redirects to pages on certain events such as moving, changing slug, and deleting a page. - -This RFC contains a proposal to add this feature into Wagtail. +This RFC contains a proposal to implement automatic creation of redirects and a couple of improvements to managing redirects in the admin interface. ## Motivation @@ -12,30 +10,59 @@ This is a highly undesirable outcome as links to those pages would be broken, an In order to prevent this from happening, editors must manually create redirects for pages that they move or change the slug of on their site, and repeat this for any child pages. This could be a tedious task and may be forgotten. -This is a task that can be quite easily handled by Wagtail. We just need to add a user interface to allow a user to specify if they want redirects to be created on moving pages or changing slugs and Wagtail can do the rest of the work. +This is a task that can be done automatically by Wagtail. + +## Prior art + +The [``wagtail-automatic-redirects``](https://github.com/themotleyfool/wagtail-automatic-redirects/) package, created by The Motley Fool, currently provides the "[Automatic creation of redirects when pages URL changes](#automatic-creation-of-redirects-when-pages-url-changes)" feature in an installable package. ## Specification -We will implement automatic creation of redirects in the following places. Note that users must have permission to add redirects in order for any of these interfaces to appear. +### ``WAGTAIL_AUTOMATIC_REDIRECTS_ENABLED`` setting + +The automatic redirects feature would be enabled with a Django setting: + +```python +WAGTAIL_AUTOMATIC_REDIRECTS_ENABLED = True +``` + +This setting will be ``False`` by default so that existing sites can opt-in to it. +This setting would be added to the project template and release notes to encourage as many developers as possible to use it. + +### Automatic creation of redirects when pages URL changes + +When the feature is enabled, Wagtail will automatically create a redirect when a page's URL changes. + +This can happen when: + + - The page is moved + - Its slug is changed + - Either of those two events occur on an ancestor page + +The redirect will be created regardless of the user's permissions to add or manage redirects. -### On page move +#### Should editors be allowed to choose when they create redirects? -We will add a new checkbox to the page move UI which asks the user if they would like to create a redirect from the old location to the new one. +We couldn't think of a case why you wouldn't want to create a redirect when a page's URL changes. +Redirects will only take effect when there is no page currently live at the requested URL so having extra redirects will not break anything. -![](https://d2mxuefqeaa7sj.cloudfront.net/s_C6D086527C63F45E9EA73587C2533A89CBE7313C89FA1DC0882B73424CAB09BB_1552329395110_Screenshot_2019-03-11+Wagtail+-+Move+Blog1.png) +### Automatic creation of redirects on page deletion -If this is checked, a redirect to the page will be created from the previous URL of the page. Redirects are also created for all descendants of the page. +When the feature is enabled, a new page chooser field (optional) would be displayed on the "delete page confirm" view. +This allows users to pick a destination page to redirect any users visiting the old URLs to. -### On page slug change +If they are deleting a tree, a redirect will be created for every page in the tree, but they will all point to the same destination. -When a page’s slug is changed, a checkbox will appear underneath the slug field asking the user if they would like to create a redirect from the old slug. +### Redirects listing filters -If this is checked, a redirect to the page will be created from the previous URL of the page. Redirects are also created for all descendants. +The redirects listing would now include three new filters on the right hand side: -Note that if the page is saved in draft, the redirects are still created but they won't take effect until the slug change is published since redirects only work if there is not already a page at the URL. + - "Redirect type" (Choice) - Filters the redirects listing by redirect type (All / Internal / External) + - "Page" (Page chooser) - When a page is chosen, the redirects will be filtered to include only those that point at the chosen page + - "Hide automatically created redirects" (Checkbox) - When checked, any redirects that were automatically created (and not subsequently edited later) would be hidden -### When unpublishing or deleting a page +### Redirects panel on promote tab -When unpublishing or deleting a page or page tree, the user will be given the option to add redirects to a page. This will also update any existing redirects pointing at the page being deleted. +On the promote tab on all pages, we will display the number of redirects that link to the page. This number would be a link to the redirects listing filtered to the current page. -Note that if the user is deleting a page tree, the user will only be able to choose a single destination page for all the redirects that get created. +This is only displayed to users who have permission to see the redirects listing.