Now that the New Year is here, we wanted to take a quick minute to share our plans for GForge Advanced Server for 2012 and beyond. As many of you know Tim Perdue, the founder of GForge, passed away last September. Since that time our team has been working on evaluating how we do business and how we can improve our products and services and we’re happy to share some exciting information about the direction of GForge Advanced Server.

Beginning immediately we are adopting a formal release schedule that our customers can count on. The release schedule is meant to make our planning efforts more efficient but, more importantly, give our customers a set schedule they can use to plan upgrades to their GForge Advanced Server instances. To that end, we will be providing two major releases per year: March and September. Major releases, as the name implies, will focus on new features and improved processes. We will also be publishing two maintenance releases each year in January and June and those will focus on bug fixes and only the most trivial of new features.

While I have had the pleasure of working with many of our customers over the past four months, I still feel many of you have some great ideas on how we can improve GForge. To that end we are about launching two new initiatives. The first initiative is a marketing survey. For the marketing survey we randomly selected customers based within specific demographics (e.g. size, organizational goals, country, etc). The customers that were selected have been contacted already and the survey will begin immediately. For those of you who did not get selected, we do welcome you to participate and to do so just send a note to feedback@gforgegroup.com indicating you want to participate in the survey and how (either email or phone). The results of the marketing survey will be used to ensure we continue moving GForge Advanced Server in the right direction for you all but, also, to help us identify and better connect with prospective customers.

The second initiative we are launching in 2012 is a customer focus group. These focus groups will occur twice annually to match up with our two major releases and the focus will be on helping us with release planning. This will be the best way to pitch new features, improvements to existing features and any other concerns you may have. The first customer focus group will occur in February or March to help us solidify our September release plan and begin on the March 2013 release. To do this, we intend to conduct these focus groups via two or three conference calls (e.g. GoToMeeting) and we will be sure all current GForge customers get notified of the dates.

A couple of other things of note is we plan to formally offer GForge Advanced Server under a Software-As-A-Service (SaaS) model toward the end of 2012. To facilitate this, we are announcing that we plan on shutting down the domain gforge.org sometime in June or July. This won’t affect many of our customers but the projects currently hosted under gforge.org will be migrated over to gforge.com along with the gforge support forum that was intended for users of GForge Community Edition and non-paying Advanced Server customers who are under the 15 user limit of the default license. Once the data migration happens we will shutdown gforge.org and begin implementation of the SaaS model under the gforge.com domain.

To wrap things up, we’d like to share our plans for the release coming out at the end of March. These plans, while not concrete, should give our you a clear picture of what you can expect in the next release and as we make changes to the release we’ll be sure to share those on our blog. The plan for the March release includes:
Addition of a GForge Daemon Process – The current GForge model uses scheduled tasks to do things like create new SCM repositories and mailing lists. The new daemon will allow much of what used to be in our scheduled tasks to occur immediately.
Document Manager User Interface Upgrade – The document manager, while functional, leaves a lot to be desired. Many of our customers said that the clunky UI simply made this feature unusable and, instead, they opted to use SCM for document storage. The user interface upgrade will make the document manager much more usable and will include basic support for file drag-n-drop into the browser.

• User-based Git Repositories – Git is gaining the lion’s share of the SCM market and user-based SCM repositories will allow for a more collaborative software environment.
• Pull requests for Git Repositories – Going hand-in-hand with user-based Git repositories, we’ll be implementing pull requests allowing cloned repositories to send pull requests to the maintainers of master Git repositories. This will make use of GForge’s existing tracker feature.
• Per-project SCM customizations – Right now GForge Advanced Server support CVS, SVN and Git but with SVN and Git you have to, on a site-wide basis, choose to use HTTPS or SSH. This release will allow the use of HTTP or SSH to be done at the project level.
• Password aging – Right now there is no default aging process for user passwords. Support for password aging wil include the ability to specify how long passwords are good before expiring.
• REST API – While our SOAP API has served us well, it introduces a slough of issues with respect to interoperability, file uploads and the SOAP payload is big. The REST API will make integrating GForge with other systems easier and will open the door for us to provide customers with mobile support on iOS and Android devices.
• Support for execution of workflow scripts – Our trackers have supported workflow implementation for years and this release we’ll be adding the ability to add hooks to execute scripts as part of a defined workflow process.
• Refresh of the Microsoft Project Plugin – The current version of the Microsoft Project plugin was written in Visual Basic 6 and only supported older versions of Microsoft Windows and Microsoft Project. This refresh is a port to .NET which will allow GForge integration into the latest versions of Project using the latest versions of the Windows operating system. We’re also happy to announce that the Microsoft Project Plugin will be free to all customers using the Enterprise Edition of GForge Advanced Server.

Some things we are considering for future releases include:

• Peer code review
• Possible Support for Mercurial DVCS
• Support for Ubuntu (mainly to make evaluation on developer workstations easier)
• Complete user interface redesign – The goal here is to reduce the number of page refreshes, boost performance and, most important, make GForge more fun to use.

Mobile support for iOS and Andriod devices – These implementations will use the REST API planned for the March release.
As you see, we have a busy 2012 planned and we look forward to working you in making GForge Advanced Server better. As always, if you have any questions please do not hesitate to contact us at feedback@gforgegroup.com.

We are happy to announce GForge AS 6.0 is ready and it sports several fixes and new features. Some of the most interesting are:

• Git over HTTP: Prior to v6.0 you could only use GForge with Git over SSH.
• CentOS6 Support: GForge AS is the first version to support CentOS6.
• User Calendars: Project members can see assigned tasks and add their own events. You can even integrate it with other calendar application via iCal.
• Blogs: GForge projects and users now get their own blog.  Please note this plugin is disabled of at the project level for customers upgrading. Also, in implementing the project blog we’ve removed the antiquated “news” system with a full fledge project blog.
• Message Walls: Gforge gets social with the addition of project and user level message walls.

You can download GForge AS 6.0 from the download page.

To those of you who didn’t have the pleasure of knowing Tim, it is best to talk about some of the sites he worked on. He was a part of the original four person team at VA Linux that built SourceForge and before that he ran PHPBuilder.com and Geocrawler.com which were sold to Internet.com and VA Linux respectively. For you younger PHP’ers out there, PHPBuilder was the number one resource for PHP development and Tim had gambled on PHP in the enterprise well before the likes of Facebook, Wikipedia and Digg.

Getting back to SourceForge, let’s face it. If you have been around the Internet and open source development you know the name SourceForge. Back in the day it hosted some of the most popular open source projects and had companies screaming for enterprise support for the product. Tim left VA Linux after the first big dotcom implosion and, after a short hiatus, picked up the open source version of the codebase turning it into GForge, his crowning professional achievement. Under Tim, GForge has grown to hundreds of customers including some very impressive names. Amtrak, BAE Systems, Cisco Systems, Texas Instruments, Massachusetts Institute of Technology (MIT) and John Hopkins University are just some of the organizations using GForge.

Tim accomplished all this coming from modest, Midwest roots. Born in Minnesota, he grew up in Swea City, Iowa and armed with an MIS degree from the University of Northern Iowa he became nothing short of a modern day myth buster. Tim proved that to succeed you don’t need an Ivy League degree, that you don’t have to live in Silicon Valley to have a successful tech company, and that you don’t need VC money to get a company off the ground. More importantly, he showed that you can create a successful business and still be a great family man.

Rest assured that we at the GForge Group are committed to continuing Tim’s vision for the company which includes top-notch customer service, continued innovation and never losing sight of good, old fashion, Midwest values.

In taking a moment to reflect on Tim’s life and his accomplishments, if you agree, as we do, that Tim was a pioneer of his time please consider making a donation to the John Stoddard Cancer Center’s Care Coordinator program.

For a project blog, only the project admin is allowed to create new posts. Simply browse to Blog->Admin and click on Add Post button, the FCK editor will show up and you can start writing your new article.

After the post has been created you will be able to add tags. Go to the Admin page and click on Edit, the tags table will be shown at the bottom.

As usual, blog posts can be commented by registered users.

Another feature of the project blog  is that for public projects, the site admin can approve a post for display on the site front page.

To access to the user blog section, browse to My Stuff page and click on the blog entry on the left menu. Any user can create his own blog and every article is readable by the rest of users.

After you install the plugin, it will be available in MS Project under the “Tools” menu item (“GForge Plug-in”).  The plug dialog shows:

Enter the GForge server you want to connect to, the serial number (you need a serial number for each GForge server), your GF username and password.  You can set it to use secure connections (SSL), if available on the GForge server.  Clicking “Fetch subprojects” will display in the drop-down below all the Trackers to which you have access to (according to the role settings in GF).  Select the desired tracker, select “Synchronize subproject” and hit “Apply” to let the plugin sync to GForge.

Consider the following GForge tracker example:

It shows a sample tracker with some tracker items.  The latest version available implements the new Hierarchical Tracker feature, to be released in the upcoming GForge 6.

Back to MS Project, after synchronization with GForge, we get the tracker items:

with the Gantt view:

Editing tracker items:

The basic operations you can do are creating / updating / deleting tasks on the tasks sheet, or manipulate start/end times and task dependencies on the Gant View.

Clicking on a task opens the task dialog:

Task dialog contents:

.General tab, you can set/edit task name, duration, start/end dates, priority

.Notes tab, you can add notes to a task, that will be added as a follow-up in the corresponding GForge task.  predecessors tab, you can assign task dependencies (make this task dependent on other tasks).

.Resources tab, you can assign human resources to the tab. This avaible resources are the same as in the assignees list in the tracker item edit screen in GForge.

Another usual management task is assigning task priorities, schedule tasks and detect and set task dependencies. That can be done directly on the Gantt view.

On the Gantt view you can:

.Move tasks along the timeline

.Expand/contract tasks

.Set task dependencies (make a task dependent on another, so that the task will start after the one upon which it is dependent on finishes).

The following picture shows an example of task dependency, where task 9 has been made dependent on task 8.

Multiple dependencies are supported. GForge tracker items support a task to have multiple dependencies:

When the manager reorganizes the tasks on MS Project, the Gantt diagram will be reflected on GForge server.

The GForge MS Project plugin is a tool specially suited to project managers that are already comfortable working with MS Project and manage projects hosted on a GForge server. It allows the manager focus on what he does: manage projects, using his tool of choice.

MS Project plugin is only available for GForge AS.

Installing it is straightforward, just decompress the distributable package in the eclipse plugin folder, then start Eclipse. You will see a “GForge” menu entry. To login to the desired server, just supply the credentials

After login in, you will see the list of projects in an expandable tree. Expanding on a project shows you a “Documents” and a “Trackers” node. Under “Documents”, you have access to all the server folders for which you have access rights to. Under “Trackers” you have the list of trackers. The icon lets you distinguish between “Task” trackers and “Issue” trackers.

Working with Trackers:

Clicking on a tracker brings the tracker window, which lists the tracker items.  From that view you can create new tracker items, edit a tracker item and run saved queries and get the resulting items listed.

To edit a tracker item, select it from the list and click “Edit”. That opens the tracker item edit view, where you have access to all the fields and tabs available on the browser-based version. The edit view is organized in tabs:

On the Tracker Item Edit View you can:

• Edit all the fields
• Add new messages (follow ups)
• See and download attached files
• See all the changes registered
• See all the commits
• Add/delete dependencies
• Add/delete duplicates
• Add/delete associations
• Add time tracker entries
• Add/delete tags

Working with documents:

Clicking on a folder under “Documents”, opens the files view.

On this view you can:

• Download a file
• Upload a file
• Edit a file

For a particular file, you can:

• See all the file versions
• Add/delete associations
• Add/delete tags

We have presented the basics regarding our GForge Eclipse Plugin.   A new version will be released together with GForge 6, that includes the new hierarchical trackers.

Hierarchical Trackers:

• Update on the powerful tracking system already existing in GForge AS.
• Lets you structure tasks as a tree.
• Tracker items can have subitems, with no limits.
• You can create trees of any depth, there’s no limit on the number of levels.
• It’s ajax based, when you expand an item, the system quickly retrieves the children items and populates the tree.
• You can assign an item as a child of another item with a simple drag and drop operation.

Calendar Plugin:

• The new calendar plugin lets you organize your tasks, share them and export them.
• Besides events created by the user, the calendar will show starting/ending tasks assigned to the user in the specified time frame.
• There are week and day views too.
• You can export individual events or the whole calendar (including tasks) to an icalendar file.
• Events marked as public can be seen by others

Blog Plugin:

• The Blog plugin comes to replace the old “News” plugin, with a much more modern look, similar to that offered by WordPress.
• Blog posts can contain rich text content with images.
• Posts can have tags associated to them, and the tag cloud lets you filter posts by keyword.
• A comments subsystem lets users post threaded comments to a post, with a quick and convenient ajax-based interface.

Social features:

• Message wall: optionally, project homepages can include a message wall, where users can post general messages or messages targeted to specific users.
  • Users can post replies to comments.
  • A post can have an attachment, such as an image or a file.
  • A post can include a link to specific sections within the project.
  • The message wall is a quick and convenient way to let users communicate within a project.
  • Users also have a personal message wall in My Stuff, where they can share private messages between them.
    
    

• User avatars: a user can upload an avatar or choose one from the existing stock avatars. Avatars are shown throughout the system, in user posts, user comments, etc

GIT over HTTP:

we added support for HTTP access to our GIT plugin.

To sum up, GForge 6 brings new an exciting features, we have described some of the major ones in this post, but there are many more news.   When the final release is ready, we will provide the full list.

Plugins basic architecture overview

There are three types of plugins in Gforge AS:

• site plugins (there is one plugin instance available to the whole site),
• project plugins (multiple instances, one per project, which can be enabled/disabled in the project admin page) and
• user plugins (multiple instances, one per user, can be activated/de-activated by regular users in the My page).

There is a set of predefined actions that a plugin will listen for. When a given action is performed, Gforge AS will notify the plugins, and each plugin will handle it. For instance, when a project is approved, the PROJECT_APPROVE notification is sent. One of the listeners, the tracker plugin, will create a set of new trackers based on the project template used when creating this new project.

Basic file layout

We need to create the plugin directory inside <gforge_path>/plugins, using the plugin name in lowercase as directory name. For the HelloWord plugin:

$ ls plugins/
build ldap scmcc snippet userwiki
docman mailman scmcvs survey wiki
forum news scmgit tracker xmlcompatibility
frs projectjabber scmperforce userblog
helloworld projectvhost scmsvn userfiles
jabber scm scmvss userjabber

Let’s take a look at the plugin directory structure

$ ls plugins/helloworld/
bin conf cronjobs languages lib wwwlib


The Gforge convention for each subdirectory:

• bin: contains scripts executables that are not cronjobs,
• conf: configurations files,
• cronjobs: scripts to be executed as cronjobs.
• languages: internationalization files,
• lib: contains all the plugins classes and functions,
• lib/html: contains the plugin template class,
• wwwlib: contains all the scripts for the web interface.
• wwwlib/admin: web scripts for the admin interface

In Gforge convention class names are CamelCased and there is one file for each class, using the class name as file name.

The GFPlugin interface

The GFPlugin interface (lib/plugin/GFPlugin.php) defines the basic methods that every plugin will need to implement:

• getType(), return the plugin type,
• getName(), returns the plugin name,
• getListeners(), returns an array of action names that the plugin will answer,
• handleAction($listenername, $params), this method, as his name implies, will handle every registered action,
• search(GFsearch $search), takes a GFsearch object and returns some result, used for project/site searches.

The plugin’s main class will implement the GFPlugin interface. The name convention for this main class is the plugin name followed by the ‘Plugin’ string. Thus, for the HelloWorld plugin, we will call it HelloWorldPlugin, and store it in the HelloWorldPlugin.php file.

GFProjectPlugin

This interface extends the GFPlugin interface adding some methods commonly used in project plugins. We will not cover it here though, since the HelloWorld plugin is a very simple one. See lib/plugin/GFProjectPlugin.php for more information.

PluginResult

This is a convenient wrapper for any result returned in response to a given action by plugins. This class provides getters and setters for the result, error status and a method to access the plugin object returning the data. See lib/plugin/PluginResult.php for more details.

The HelloWorld plugin

Now we can start writing our HelloWorldPlugin class definition, first we need to know what classes we will use. We already explained GFPlugin and PluginResult, the ActionManager class handles the actions notifications and other interactions between the plugin and the Gforge core, GFUrl generates and parses Gforge’s urls and Language is a set of tools to handle language translations.

<?php
require_once('plugin/GFPlugin.php');
require_once('plugin/ActionManager.php');
require_once('plugin/PluginResult.php');
require_once('core/Language.php');
require_once('GFUrl.php');

The first method we implement is initialize(), this method will register the actions that this plugin will answer using the ActionManager::registerListeners() method.

class HelloworldPlugin implements GFPlugin {
+++ CONST ALLOW = 1;
+++ CONST DISABLE = 0;
+++ CONST SECTION = 'Helloworld';


+++public function initialize() {
++++++ActionManager::registerListeners($this,
++++++$this->getListeners());
++++}

getType() returns the plugin’s type, in this case a project plugin.

public function getType() {
+++return GFPlugin::PROJECT_PLUGIN;
}

getName() will return the name of the plugin, in lowercase.

public function getName() {
+++return 'helloworld';
}

getListeners() just returns an array of strings containing the action names that this plugin listens.

public function getListeners() {
+++return array(
++++++'BUILD_PROJECT_TABS',
++++++'GET_NAV_ELEMENTS',
++++++'GET_OBSERVER_ROLE_CHOICES',
++++++'GET_ROLE_CHOICES',
++++++'PROJECT_APPROVE'
+++);
}

handleActions() maps actions into methods. Don’t worry if you don’t know the meaning of every action, we will see a brief description later.

public function handleAction($listenerName, $params) {
+++switch ($listenerName) {
++++++case 'BUILD_PROJECT_TABS': {
+++++++++return
+++++++++$this->_buildMainTabsListener($params);
+++++++++break;
+++++++}
++++++case 'GET_NAV_ELEMENTS': {
+++++++++return $this->getNavElements($params);
+++++++++break;
++++++}
++++++case 'GET_ROLE_CHOICES': {
+++++++++return $this->getRoleChoices($params);
+++++++++break;
++++++}
++++++case 'GET_OBSERVER_ROLE_CHOICES': {
+++++++++return $this->getObserverRoleChoices($params);
+++++++++break;
++++++}
++++++case 'PROJECT_APPROVE': {
+++++++++return $this->approveActions($params);
+++++++++break;
++++++}
+++}
}

Since this plugin will not return any data on searches, we can write just a stub for the search() method.

public function search(GFSearch $search) {
}

The next two methods are mandatory although not specified in the GFPlugin interface but in GFProjectPlugin. To avoid unnecesary complexity and for historical reasons the HelloWorld plugin implements the GFPluing interface, but when you write a real project plugin you should always implement GFProjectPlugin.

disableFromProject() as its names implies, disables a plugin from a given project. It will be called from a Project object when disabling the plugin. We only need to unregister the actions that the plugin is listening, the caller will take care of everything else.

function disableFromProject() {
+++// unregister the actions
+++ActionManager::unregisterListeners($this);
}

enableInProject() will be called by a Project object when the plugin is enabled, it’s safe to write just a stub here.

function enableInProject(Project $project) {
+++return;
}

HelloworldTemplate

This class extends ProjectTemplate (lib/html/ProjectTemplate.php) and overrides two methods: header() and getPluginNavElements(). The first method will set the page title and it will add the breadcrumb for our plugin. The second method will add navigation elements to the plugin entry in the left side menu, as we will see later

Actions

BUILD_PROJECT_TABS

The left menu entry for HelloWorld

The first action we need to handle is BUILD_PROJECT_TABS. This signal is sent by the secondTabs method inside the Layout class (lib/html/Layout.php), around line 674:

$prs=ActionManager::notify("BUILD_PROJECT_TABS",$params);

The method expects a collection of PluginResult objects to render the left menu on the project view. So, here is our method to handle this action:

private function _buildMainTabsListener($params) {
+++if(!isset($params['project']) ||
+++!is_object($params['project']) ||
+++!$params['project']->usesPlugin($this->getName())) {
++++++return;
+++}
+++$project = $params['project'];
+++$result = new PluginResult($this);
+++$value = array(
++++++'text' =>
++++++Language::getSessText('Helloworld.TabString'),
++++++'action'=>
++++++GFUrl::getUrl()->projectURL($project,'','helloworld'),
++++++'id'=> 'helloworld'
+++);
+++$result->setResult($value);
+++return $result;
}

First we check if a project object is present in the $params array, and if our plugin is active for that project. Then, we define some data expected by the caller to build the left side menu and we return it inside a PluginResult object.

Language translation

This line in the previous code snippet

Language::getSessText('Helloworld.TabString')

uses the Language class, which provides a convenient tool for language translation. This class expects languages files inside the languages subdir in the plugin’s subtree, where the general format is:

TagName<tab>Message

Base.tab should contain english messages. See the plugin’s source for more examples on other languages.

GET_NAV_ELEMENTS

This signal is sent from HelloWorldTemplate::getPluginNavElements() function which we already covered. It will insert submenu entries below the plugin entry in the left menu, as you can see in the next screenshot.
Insert image here.

navigation elements in the left menu

GET_ROLE_CHOICES and GET_OBSERVER_ROLE_CHOICES

When this signal is sent the plugin will return a data structure contaning the available permissions that can be set for a given project. We will only use HelloWorldPlugin::ALLOW and HelloWorldPlugin::DISABLE here, but other plugins implement more complex permissions.
GET_OBSERVER_ROLE_CHOICES is similar except that the plugin must return available permissions for non-members (usually private and public). See the source code for details about the implementation.

PROJECT_APPROVE

This signal is sent when a project is approved. HelloWorldPlugin::approveActions() does nothing actually, but you can see a well commented example from the mailman plugin.

The web interface

Scripts that handle the web interface are stored in plugins/helloworld/wwwlib. The first thing to notice is a file called handler.php, which is a dispatcher. This file will map the parameter ‘action’ in the URL to a given script. The default action is handled by index.php, we use the HelloWorldTemplate object to print the page header and footer

<?php
getLanguage();
$Project = GFUrl::getUrl()->getProject();
require_once('plugins/helloworld/lib/html/HelloworldTemplate.php');
$theme = new HelloworldTemplate();
$params = array(
+++'title' => 'Index',
+++'project' => $Project,
+++'selectedbottomtab' => 'helloworld'
);
$theme->header($params);
?>
Hello world!
footer($params);
?>


Hello world main page view

Installation

The final step is to install our new plugin, first we need to copy the source files to plugins directory in the gforge installation, and add an entry into the plugin table for HelloWorld.

INSERT INTO plugin(plugin_name, plugin_desc, plugin_type, plugin_order, exclusive_type)
VALUES ('helloworld', 'A hello world plugin', 'project',
(SELECT max(plugin_order) FROM plugin WHERE plugin_type='project') + 1,null);

Finally, we must run upgrade.php to update the configuration and language cache.

#cd /opt/gforge5 && php upgrade.php

This tutorial is not a comprehensive guide, but we covered the basics to start writing your own plugin for Gforge, the best documentation you can get is in the source code of the main plugins bundled with GForge AS.

A worklow engine, like the one implemented in GForge AS, is an automation software that lets program the procedures, steps and rules of a certain workflow.  The engine will determine when the process is ready to move forward to the next step (or backwards, if defined in the worklow). When the requirements for moving to another step are met, the engine will proceed automatically, assigning resources and notifying the people involved.

How does workflow automation work in GForge AS:

The workflow engine works by defining “transitions” or “transition rules” in the specified field/fields of a tracker. It applies to fields that have a set of possible values. You can define transitions between pair of values, i.e.: the transition applies when that field changes from one value to another. Therefore, you can have as many transitions on a single field as the number of possible pair of values (values must be different, of course).

On a transition, you can define the following:

• Roles that can make the transition: you can define a set of roles that are allowed to make the transition
• Required fields: you can define which fields are required to be set
• Notify people when the transition occurs: you can add a message (text) and select a set to roles to be sent that message
• Reasign the item to the specified roles: you can select a set of roles that will have the item assigned after the transition
• Change a field value: you can select a field and specify its new value.

A real life (almost) example:

Say we have an issue (bug) tracker in a certain software project. This tracker is used for managing issues that appear on a testing phase. So, The QA people report those issues in this tracker as they appear. A junior developer validates the issue, finds possible causes, etc, then reports and passes the isue to the senior developers for fixing.

Let’s suposse we have three different modules on this software. Each module is managed by a group of junior developers. A first automation we may want to enable is to have the issue, depending on the module where it appeared, automatically assigned to the corresponding junior developers group.

When the junior developer is done validating the issue, we want it routed to the senior developer for fixing.  Once the senior developer fixes it, it’s routed back to QA for retesting and validating the fix.  When in QA, if  it doesn’t validate, it gets routed back to the senior developer.

To summarize, the task will cycle through the different stages, being automatically routed, until QA decides it’s fixed so they can close it. Wokflow automation gets tasks assigned to people depending on specified conditions.

Description of the different “stages” or “phases” and “actions” of a task in the example workflow:

a) Issue is entered by a QA member, “state” is set to “Awaiting response” (default “state” setting).  Depending on the “component” field setting, the issue is auto-assigned to certain user/group of the Junior Developers role

b) The junior developer tries to reproduce the issue, and sets the state to either: “Accepted as Bug”, “Works for me” or “Invalid”.

b.1) if set to “Accepted as Bug” we want the issue to be re-assigned to a Senior Developer and notify the project admin and the QA members

b.2) if set to “Works for me”, we want to reassign the issue to QA to get evaluated and closed.

b.3) if set to “Invalid”, we want the item be closed and notify QA.

c) When the Senior Developer gets an issue assigned, he/she will attempt to fix it and then set the issue “state” to “Fixed” or “Won’t fix” accordingly.

c.1) if set to “Fixed”, we want the issue reassigned to QA for retesting.

c.2) if set to “Wont-fix”, we want to notificate the project admin, but the issue doesn’t get re-assigned to other role.

d) For issues that were reassigned to QA for retesting, one of the following may happen:

d.1) Issue doesn’t validate as fixed, “state” is set to “Not Fixed” and gets automatically reassigned to “Senior Development” role for rework. Project admin gets notified.

d.2) Issue validates as fixed, tester sets “state” to “verified”. “Status” is automatically set to “closed”, and senior developer and project admin get notified.

Sample workflow diagram:

To summarize, workflow automation facilitates collaboration across departments and individuals. It streamlines the process and helps running the business more efficiently.

How to create this sample workflow in GForge:

You can use the default bug tracker that comes with GForge to create this sample workflow and see how it works.

1. Create a test project based on the standard template that comes with GForge

2. Go to “Tracker >> Bugs”

3. In the Bugs tracker go to “Admin >> Edit Fields, Auto-Assign, Workflow”

4. Select the “Component” field in “Auto assigned By” and submit.

5. Go to “Edit Field Values” in the “Component” field.  Enter some values (component names) and assign user/group to each one. If you don’t have users or groups on your test project, go ahead and create/assign
them first.

6. Back on the “Edit Fields, Auto-Assign, Workflow”, check the “Resolution” field on the “Workflow” column and submit. This indicates that we want to set a workflow on this field.

7. Click on “define”, you will see the transitions matrix. Check the transitions as shown in the following screenshot and submit. Notice here that we are selecting the transitions described in the above worklow description (check the diagram).

8. We will show how to define one of those transitions, you can create the rest yourself repeating this process.  Click on “Details” for the “Awaiting Response” >> “Accepted as Bug” transition.

9. Here we set the transition rules and actions, set the different fields as shown in the screenshot.

10. You can repeat steps 7 to 9 to define the rest of the transitions we created. Set the “roles that may make this change” and “reassign item to role” accordinly in each case. You can see the complete list of
transitions for a certain tracker if you go to “Tracker >> Worklow rules”:

11. Your worklow is ready to use. Go ahead and create a tracker item, set it to “awaiting response”. Then  login with a junior developer role, then with a senior developer, etc. Simulate the actions that each role can take while working on the item and see how the transitions occur automatically when the conditions are met.

We have given an introduction to working with workflows in GForge AS.  It’s a very powerful feature that can radically improve the efficiency of the organization.  We invite you to implement the example we discussed in this post and see for yourself.

MAG2 is based in the previous MAG for Gforge 4.x series.

Installation

Pre-compiled binaries for RHEL4/5, as well as the source tar (for compilation on other platforms) can be found here. Debug packages are also available.

We will cover the rpm installation here. If you need or want to compile from source, detailed instructions can be found in the README file distributed with the source tar.

On a working Gforge AS installation, all the runtime dependencies needed by MAG2 are installed by default, so it is just a matter of downloading the proper package for your RHEL version/architecture and install it with the rpm command as usual.

rpm -i modauthgforge2-0.6-1.i386.rpm

There is a debug version of each package too, which provides debugging information.

Configuration

Once installed, you need to instruct apache to load the module, which is done with this line.

LoadModule auth_gforge_module modules/mod_auth_gforge.so

Make sure you load the auth_gforge_module after dav_module and dav_svn_module. Also, remember to remove mod_authz_svn from the module list to be loaded by apache at startup. In Centos/RHEL, check /etc/httpd/conf.d/subversion.conf  also to confirm mod_authz_svn is not being loaded.

The configuration options are explained in the README file, which you can find in /usr/share/doc/modauthgforge2 if you installed MAG2 using rpm, or inside the source tar if you compiled from source. Here is an example using the standard /etc/gforge/httpd.conf file installed by default with Gforge AS:

LoadModule dav_module         modules/mod_dav.so
LoadModule dav_svn_module     modules/mod_dav_svn.so
#LoadModule authz_svn_module   modules/mod_authz_svn.so
#Uncomment this to load MAG, comment out the previous line
#(authz_svn module)
#and make sure the authz_snv_module is not loaded in
#/etc/httpd/conf.d/subversion.conf
LoadModule auth_gforge_module modules/mod_auth_gforge.so

Inside your virtual host directive:

#
#  SVN Repository
#
    <Location svn>
      ErrorDocument 404 default
      DAV svn
      SVNParentPath /var/lib/gforge/svnroot
      #Uncomment the following lines to use MAG
      GforgeSysPath /var/lib/gforge
      GforgeGroupsRoot /svnroot
      Auth_PG_cache_passwords On
      # how to authenticate a user
      # comment out the following line when using MAG
      #AuthzSVNAccessFile /var/lib/gforge/svnroot-access
      AuthType Basic
      AuthName "Document repository"
      # comment the following line when using MAG
      #AuthUserFile /var/lib/gforge/svnroot-authfile
      SVNIndexXSLT "/svnindex.xsl"
      # only authenticated users may access the repository
      Require valid-user
    </Location>

You may need to configure the database parameters as well. Check the README for Auth_PG_host_name, Auth_PG_database, Auth_PG_port and Auth_PG_pwd. If you accepted the default database parameters when installing Gforge, this is not needed.

For more details, please check the README

Final steps

Once the above steps are done, and you confirmed that everything works, you can disable the cronjob that handles webdav users creation/modification. Look into cron15.php and comment the following line:
`$base_str/plugins/scmsvn/cronjobs/create_dav_svn_auth.php`;

About anonymous access

A current MAG2 limitation is that an user needs to be registered at the site for checking out projects when he is not a member and the repository anonymous access is enabled.