#458  Allow users to access repositories by name (Web UI URL)
Closed
Marcos de Oliveira opened 7 months ago

After introducing the repository chaining feature, we could not access repositories by their names anymore.
I think the current behavior is because of parent project's URLs (issues, branches, commits, etc). But maybe you could introduce some reserved words for repository names to avoid collisions and use internal routes to access the child repositories panels by URI.

Robin Shen commented 7 months ago

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.

Marcos de Oliveira commented 7 months ago

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.

Robin Shen commented 7 months ago

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.

Robin Shen changed state to 'Closed' 7 months ago
Previous Value Current Value
Open
Closed
wojtek commented 3 weeks ago

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?

Robin Shen commented 3 weeks ago

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?

wojtek commented 3 weeks ago

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.

Robin Shen commented 3 weeks ago

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.

wojtek commented 2 weeks ago

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.

Robin Shen commented 2 weeks ago

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

wojtek commented 2 weeks ago

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)

Robin Shen commented 2 weeks ago

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.

wojtek commented 2 weeks ago

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...

Robin Shen commented 2 weeks ago

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.

wojtek commented 2 weeks ago

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")

Robin Shen commented 2 weeks ago

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.

wojtek commented 2 weeks ago

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)?

Robin Shen commented 2 weeks ago

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...

issue 1 of 1
Type
Improvement
Priority
Normal
Assignee
Issue Votes (0)
Watchers (5)
Reference
issue onedev/server#458
Please wait...
Page is in error, reload to recover