An organization or a project with the slug 'new' or a user with the username 'add' will conflict with the add functions

[seav]

Currently, the URLs to add a new organization, project, and user are:
/organizations/new/
/organizations/<org-slug>/projects/new/
/organizations/<org-slug>/members/add/

And the URLs to view the organization and project, and to edit the org member permissions are:
/organizations/<org-slug>/
/organizations/<org-slug>/projects/<project-slug>/
/organizations/<org-slug>/members/<username>/

If the org or project slug is 'new' you can't view the organization or project at all. If the username is 'add', you can't use the above URL to edit this user's permissions. You need to go into each project and change the user's permissions there instead.

[wonderchook]

@seav are there any other similar situations to this?

[seav]

Probably, but I haven't checked thoroughly. I only noticed this particular bug when I was fixing #263.

[seav]

I looked at the code and tried it on the platform: Organizations and Projects named "New" will conflict with the add new organization and add new project functions.

[oliverroick]

There are three ways we can solve this:

1. Change the URL pattern from /organizations/{slug}/projects/new/ to something like /organizations/{slug}/create-project/
2. Make sure you can't use new or add as a name for projects or users.
3. If we want to allow new or add as names (seriously, who does that?) we can make sure the corresponding slug is automatically changed to something different, e.g. project-new. That works for organization and project slugs, but it's not a very nice solution for usernames.

[seav]

I prefer solution № 1.

[wonderchook]

I think number 2 is the most simple answer at this point and what we should do.

[seav]

Is this decided? We can modify the forms and serializers to validate that the slug or username is never 'add' nor 'new'.

[wonderchook]

Yes it is decided. We should do the validation for now.