Repository access link not shown without permissions for the parent project

[eudoxos]

The repository access link git clone ssh://git@server/proj/subproj is not shown to a user who is member of subproj but not of proj. He reports seeing

REPOSITORY ACCESS LINKS

Repository access not configured, please contact your adminstrator.

whereas I see the correct link there.

If you need more details, I will ask him to provide more; if you need logs, tell me which ones and you will have them.

[oliverguenther]

This is no flaw.

In OpenProject, you have to add the user to the parent project. Otherwise only the subproject is visible to him. The permissions do not propagate to the parent.

[eudoxos]

He was able to use the repo after I sent him the correct URL by hand (ssh://git@server/proj/subproj), so there is clearly a mismatch between what OP thinks about the permissions and what gitolite actually allows.

He does not see proj as project in OP (since he's not a member of it), only subproj, but proj is a part of the URL for subproj which is perfectly accessible for him.

I would suggest though to show the correct URL to the user (it really only discloses the parent's project name, nothing more) than saying that there is not repo for the project (which is not true) and he should contact the admin about it -- which is me and I don't want people to be instructed to bug me ;) (just kidding).

What do you think?

[oliverguenther]

Ah, I see. I thought you meant the user of subproj should be able to see (and is able to access) the repo of proj, which would be a horrible mistake ;)

However, I cannot reproduce the error. To what permissions did you set the affected user in subproj? If he was assigned read-only access, the plugin decides it should print only the public git-protocol clone URL, which isn't implemented in the OP port so far. My test setup contains the following projects:

• Project foo, foo/bar with repositories each
• User aliceis a manager of foo, and user bobis a manager/developer of foo/bar.

They both can see the git checkout URLs.

[eudoxos]

In my case, it would be this:

• alice manages both foo and foo/bar; there is a repository for foo/bar created.
• bob is a member of foo/bar, but has no access to foo at all (thus, he sees only bar in project listing, not foo/bar)
• actual result: bob sees "Repository access not configured" when opening bar's repository .
• desired result: bob sees ssh://git@server/foo/bar

[oliverguenther]

Okay, I guess there are still some issues with the gitolite_ssh_key permissions in OpenProject. I don't see the need for those permissions anway, so I removed them for now. Please pull e8657d5 to see if this fixes the error. :)

[eudoxos]

Not sure if there is some caching taking place; I created a test user which has all the permissions but (unlike myself) does not see the repository URL for the nested project, whatever settings I tried (manager of both projects, member of both, of the nested one only etc). Is the user added to gitolite automatically, with repository being set-up before the user himself? I have no idea what's going on... :|

[oliverguenther]

Could you mail me or link the generated openproject.conf along with a list of the affected repositories and their member permissions? There may be an issue of regenerating the configuration.

I'm preparing a larger pull request into dev that unifies the configuration and reduces the codebase by removing remnants of the forked project. With it , you can use the resync all projects option in the settings to force the plugin to regenerate the openproject.conf entirely.

The PR btw also changes the way git repositories are accessed from OpenProject. Sudo access is no longer required, however openproject must be added to the git group and the gitolite umask must be extended to allow group access. Read more about the change here

[eudoxos]

I confirm this issue (people not seeing ssh link for repos) is fixed with the new revision, though only after fixing the launch script of the packaged installation to pass --groups git, as writte in private mail. Thanks!