Preliminary implementation of server-side forking (issue 137)

The fork mechanism clones the repository , access restrictions, and
other config options.  The app has been updated throughout to handle
personal repositories and to properly display origin/fork links.

In order to fork a repository the user account must have the #fork role,
the origin repository must permit forking, and the user account must
have standard clone permissions to the repository.

Because forking introduces a new user role no existing user accounts can
automatically begin forking a repository.  This is both a pro and a con.

Since the fork has the same access restrictions as the origin repository,
those who can access the origin may also access the fork.  This is intentional
to facilitate integration-manager workflow.  The fork owner does have the
power to completely change the access restrictions of his/her fork.

1 files changed, 8 insertions, 0 deletions

diff --git a/src/com/gitblit/wicket/pages/ProjectsPage.java b/src/com/gitblit/wicket/pages/ProjectsPage.java
index f3c4416e..7161d0f3 100644
--- a/src/com/gitblit/wicket/pages/ProjectsPage.java
+++ b/src/com/gitblit/wicket/pages/ProjectsPage.java
@@ -36,6 +36,7 @@ import org.eclipse.jgit.lib.Constants;
 import com.gitblit.GitBlit;

 import com.gitblit.Keys;

 import com.gitblit.models.ProjectModel;

+import com.gitblit.models.UserModel;

 import com.gitblit.utils.MarkdownUtils;

 import com.gitblit.utils.StringUtils;

 import com.gitblit.wicket.GitBlitWebSession;

@@ -63,6 +64,13 @@ public class ProjectsPage extends RootPage {
 	protected boolean reusePageParameters() {

 		return true;

 	}

+	

+	@Override

+	protected List<ProjectModel> getProjectModels() {

+		final UserModel user = GitBlitWebSession.get().getUser();

+		List<ProjectModel> projects = GitBlit.self().getProjectModels(user, false);

+		return projects;

+	}

 

 	private void setup(PageParameters params) {

 		setupPage("", "");