What's the problem this feature will solve?
Aliases can change, or not follow the same rules as other identifiers (like including a slashes), this can conflict with our URLs.
With support for slashes in subprojects, we have /api/projects/project/subprojects/my/subproject/alias instead of /api/projects/project/subprojects/subproject-slug/.
I checked and in .org we have:
- 5020 subprojects
- 3168 subprojects where their alias doesn't match their slug
- 650 requests in the last 30 days to the subprojects API (see CF)
- 43K requests in the last 30 days to the page redirect, but looks like it's just 3 projects mainly. (see CF)
- 3189 subprojects have downloadable content, 1931 from those don't have an alias matching the slug. The URL to download files doesn't have an easy part to identify if the download is from a subproject, and CF doesn't have a way to match patterns, so I wasn't able to get the number of downloads of the past 30 days...
On .com:
- 1541 subprojects
- 1347 subprojects where their alias doesn't match their slug
- 66 requests in the last 30 days to the subprojects API (see CF)
- 1.8K requests in the last 30 days to the page redirect, looks like only one project. (see CF)
- 931 subprojects have downloadable content, 783 from those don't have an alias matching the slug. The URL to download files doesn't have an easy part to identify if the download is from a subproject, and CF doesn't have a way to match patterns, so I wasn't able to get the number of downloads of the past 30 days...
Our dashboard views use the subproject slug as URL identifier, it's only the API, downloads, and page redirect that use the alias as identifier. Of the previous numbers on CF, some of those projects, their alias matches their slug.
We could change our code to accept project slugs instead of their aliases, and to avoid breaking previous URLs, we could have a feature flag that is applied to all parent projects of the existing subprojects where their subproject alias doesn't match their slug, we would fall back to check the slug too, so those projects can migrate in the future.
Additional context
#13007
What's the problem this feature will solve?
Aliases can change, or not follow the same rules as other identifiers (like including a slashes), this can conflict with our URLs.
With support for slashes in subprojects, we have
/api/projects/project/subprojects/my/subproject/aliasinstead of/api/projects/project/subprojects/subproject-slug/.I checked and in .org we have:
On .com:
Our dashboard views use the subproject slug as URL identifier, it's only the API, downloads, and page redirect that use the alias as identifier. Of the previous numbers on CF, some of those projects, their alias matches their slug.
We could change our code to accept project slugs instead of their aliases, and to avoid breaking previous URLs, we could have a feature flag that is applied to all parent projects of the existing subprojects where their subproject alias doesn't match their slug, we would fall back to check the slug too, so those projects can migrate in the future.
Additional context
#13007