As OneDev evolves, reserved names will expand, and this may conflict with existing project names. Also id will not change even if project is renamed/moved/archived etc.

I see... Maybe there is a way to do some fuzzy search to match and redirect to the repo ID then, instead of returning 404 directly? My point is that there should be a way to link to a repository by name so people know what they are accessing beforehand. Also, being able to go to a repo by URL would be nice.

This turns out to be difficult with Wicket (web framework used by OneDev) as it expects fixed segments for pages. Since project path now contains arbitrary number of path segments (/project1/child1/child2 etc), it breaks url routes of OneDev pages. The only possible way is to encode path separator / so url will look something like http://onedev-server/project1%2Fchild1%2Fchild2 which seems ugly. The id approach is performant (no need to query path and sub path for project), stable, and easy to implement, with the only exception of not readable, which can be addressed to some extent with link text.

Sorry for bumping closed issue but - does the structure has to be reflected in the URL? It seems that with ID the structure is not included in the URL, and having uniquely named projects (possibly in user scope?) would mean that something like http://onedev-server/user|org/project/issue|build|etc. could be possible?

It is rather difficult, since project can be nested multiple levels. And this means that there are ambiguous if project name is used in path, for instance, for /onedev/server/issues, how to tell you want to access issues page of onedev/server, or dashboard page of project onedev/server/issues?

I'm not exactly sure I understand your message and example above. I think the misunderstanding comes from the constrain I was thinking of - basically project names would be unique globally (or within user/organisation, along the line of GitHub's notion of https://github/<username>/<project> which would be convenient with forking to user's own space). In that case there is no issue with name conflict and associating it with project ID.

I mean if you have two projects myproject, and myproject/issues. Given the url http://server/myproject/issues, how to tell if the user wants to access issues of project myproject, or default page of project myproject/issues.

We can of course to not allow OneDev projects to use reserved names such as issues, files, settings (and this list is long). But it is difficult to list all of them considering future development of OneDev.

Another approach is to prefix all internal url segments with some special character, for instance:

http://server/myproject/~issues http://server/myproject/~settings

But this seems to me more ugly than using project number.

I think that using slash ( / ) or other special characters in project name should be prohibited as it only causes issues like the one here. If that's removed then I don't see a problem as the URL structure would be quite rigid: https://<onedevserver>[/user|organisation]/<project name>/<project section> where the last part would be issues, settings, files, builds, etc.

OneDev projects can nest child projects to form a path like structure.

I'm aware of that but from what I can see it looks like the project-id is always from the selected project, i.e. https://<our_server>/projects/31 (parent project) list the child projects and one of them is for example https://<our_server>/projects/11. I see nowhere in the URL parent/child relationship.

Even on this instance you have https://code.onedev.io/projects/392 which list 2 child projects and then child project is just https://code.onedev.io/projects/395 and NOT https://code.onedev.io/projects/392/395 (that would be ttps://code.onedev.io/projects/sierra and https://code.onedev.io/projects/sierra/onedev-server)

This is because I am using project id to represent project. If you want to use project name, you will need to specify all parent project names along with current project name like onedev/server to represent this project.

Circling back to my previous argument: you can simply make project names unique, either globally or within user/organisation scope (which then should be included in the URL). I'd even argue that having unique project names would be somewhat helpful to avoid confusion as to which project are you using...

That will be too limited. Even with that, you still need to make sure it does not conflict with reserved names such as issues, settings, etc.

Why it would be too limited? I'd argue that having two projects with same name would be quite confusing. Same goes for allowing project names with reserved names (e.g. creating project named "settings")

We ourselves have many projects of same name. For instance: projectA/production, projectB/production, etc. Also when forks a project, OneDev creates sub project of same name under a project named by user account.

Forcing project names to be unique in a tree structure is really a bad idea to me.

OK, but you still differentiate between organisation/user (projectA/projectB seems like organisation) and also on the username basis (which is quite natural for forks and works as such under github/gitlat/gitea AFAIR). For this reason I was arguing that unique project name within organisation/user account indeed seems logical - would you have two projects like projectA/production and projectA/production (with different id so in current implementation it would be code/onedev.io/projects/160 and code/onedev.io/projects/161)?

There is no built-in organization/user concept to organize projects in OneDev. It is just a convention to create a parent project with same name as the user forking the project, and then place the forked project under that parent project.

Every project in OneDev is using the same object type, and this has tremendous advantages as you can nested them in multiple levels, and child projects can inherit settings from parent project...

The clone functionality identifies the repository by name, couldn't an automatic redirect be implemented?

For example: https://code.onedev.io/onedev/server -> https://code.onedev.io/projects/160

OneDev can easily identify the clone connection out of web connection, and clone url only has one format: http://server/path/to/project. There is no ambiguity here.

Nitpick, k8s documentation (https://code.onedev.io/projects/162/files/5.0/pages/deploy-into-k8s.md) still uses project name in the url (https://code.onedev.io/projects/onedev-server/builds?query=%22Job%22+is+%22Release%22) which returns an error...

I would still argue that you can still have parent/child (and inheritance of projects) without ambiguity in links in the same manner that you can have project name in git clone links.

This doc is outdated. OneDev now deploys into k8s via helm.

That wasn't the point - the point was it used project name in the URL and it would work.

That is because in that release, OneDev projects do not support to be organized in a tree structure yet.

I would like to go back to this issue and revise it. I understand the motivation (multi-level project grouping) but... it's less readable and simply doesn't work beyond simple nesting. I just imported some projects and decided to take advantage of the more complicated project structure. In the end it was <org_name>/<component_group>/<project> (so, simply one more level)

Result:

• <project> has set parent as <org_name>/<component_group> and in the page breadcrumb I saw: `Projects > org_name > component_group > project
• project URL was https://<host>/projects/389/, clone URL was: https://<host>/<org_name>/<component_group>/<project> - as a result it wasn't possible to clone the repository with fatal: remote error: Unable to find project '<org_name>/<component_group>/<project>'
• I edited the project and set parent as <org_name> simply - cloning started to work with https://<host>/<org_name>/<project>
• I tried to edit the project and set the parent back to <org_name>/<component_group> (which exists, and it was available in the dropdown) yet got the red error: "Parent project not found"

I would say that simplifying grouping (having only notion of scopes, like user or organization) would be more than sufficient and probably would help avoid issues like above. What's more, linking and cloning would be more informative - user would know that link https://code.onedev.io/onedev/server leads to onedev server repository, and opening link https://code.onedev.io/projects/160 gives virtually zero information to where the link points. I mention this because I assume fix for the cloning will be using project-id as well in the git clone, which will result in reducing information which repo we are actually cloning, e.g.: https://code.onedev.io/projects/160…

None of the issues you are encountering exists at my side with 7.5.1.

Possibly issues were caused by https://code.onedev.io/projects/160/issues/923

However, I would like to circle back to the main topic here - using project names to access them. We currently have multi-level projects. Those projects use https://<host>/projects/389/ URL (ie. exact project-id in the URL). Your main argument to use project-id and against actual project-names was that it would case ambiguity. The slight problem with this line is that... git clone command uses actuall project names in the URL (i.e. https://<host>/<org_name>/<component_group>/<project>) and... it works. I would argue that the same URLs that are used for git clone / repo URL could still be successfully used for project navigation.

You had two suggestions previously:

1. create list of restricted keywords
2. prefix internal pages.

I think that (2) would be more than enough and having https://<host>/<org_name>/<component_group>/<project>/~issues would still be nicer and more readable than https://<host>/projects/389/issues (what's more, even more informative that we are actually accessing "internal page"). But if that's not the case, wouldn't it be possible to gather all internal pages endpoint names and automatically create list mentioned in (1)? This seems doable. Though, looking at the sources in io.onedev.server.rest it seems everything is based on javax.ws.rs.Path thus using prefixes in second option would be way simpler.

That would also "fix" problem mentioned in server#923 with inflated project-ids after failed import and re-import - those IDs wouldn't be visible anymore.

tl,dr; Prefixing internal 1dev pages (~settings, ~issues, etc) IMHO doesn't look ugly and would be way better than using numbering project-id in the URL.

That's a very good approach, IMO. I didn't even thought about prefixing internal pages, I think that's the real fix and something that GitLab does, although, slightly differently, as they prefix internal pages by '/-/'. Something like https://code.onedev.io/ondev/-/issues and https://code.ondev.io/onedev/server/-/issues might be feasible.

But if that's not the case, wouldn't it be possible to gather all internal pages endpoint names and automatically create list mentioned in (1)? This seems doable.

That is not really an option because the list could contain words that conflict with already existing projects. This would break during upgrade unless you automatically rename these projects.

Prefixing internal pages is also only an option if the prefix character sequence is currently disallowed in project names. So ~ would work but _ would not (since projects are currently allowed to start with _).

Thanks for all your input. Will explore the option of prefixing internal pages with special character.

Awesome, thanks!

Thank you, Robin! Is there an (related) issue that could be tracked?

Issue reopened. Just use this to track.

OK, thank you :-)

State changed as code fixing the issue is committed

State changed as build #3146 is successful

Thank you very much!

Great, thank you Robin!

Seems like emails are not using the new URL format yet.

On a related note, trailing slashes cause an error. Example: https://code.onedev.io/onedev/server/

@davidebeatrici the trailing slash issue has been fixed in build #3149

As to email not using new url format, can you please share a screenshot?

Looks like it's fixed now, the email I received as notification for your message uses the new format.

Hi there, and thanks for the effort taking back to us the pretty URLs :)

I’m a bit concerned about the fact that it’s a breaking change for all the links over the interwebs pointing to the old urls schema. Basically if I update my OneDev instance I must modify all the external links to my projects because the old /projects/$id paths will return a 404.

I’ve something like ~1400 projects linked basically everywhere ?? (and not all the links are in a place maintained by me).

Could you be so kind as to provide a programmatic url rewrite (or a 301 redirect at least) to maintain backwards compatibility?

Thank you (:

@crash I understand the situation, will try to make old urls working also in next one or two releases. Please watch issue #1008 to get notified.

Thanks Robin, very appreciated!

absolutely no rush, take all the time you need for that.

I’ll post some of my considerations about it on the issue #1008

cheers, crash