Projects onedev server Issues #458
#458  Allow users to access repositories by name (Web UI URL)
Open
Marcos de Oliveira opened 12 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 12 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 12 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 12 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' 11 months ago
Previous Value Current Value
Open
Closed
wojtek commented 6 months 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 5 months 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 5 months 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 5 months 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 5 months 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 5 months ago

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

wojtek commented 5 months 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 5 months 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 5 months 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 5 months 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 5 months 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 5 months 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 5 months 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 5 months 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...

Davide Beatrici commented 4 months ago

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

Robin Shen commented 4 months ago

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.

wojtek commented 4 months ago

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.

Robin Shen commented 4 months ago

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

wojtek commented 4 months ago

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

Robin Shen commented 4 months ago

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

wojtek commented 2 months ago

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

Robin Shen commented 2 months ago

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

wojtek commented 2 months ago

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.

Marcos de Oliveira commented 2 months ago

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.

jbauer commented 2 months ago

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

Robin Shen commented 2 months ago

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

Robin Shen changed state to 'Open' 2 months ago
Previous Value Current Value
Closed
Open
Davide Beatrici commented 2 months ago

Awesome, thanks!

wojtek commented 2 months ago

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

Robin Shen commented 2 months ago

Issue reopened. Just use this to track.

wojtek commented 2 months ago

OK, thank you :-)

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