Hi Justin,
I'm glad to hear of still more federal agencies making use of our code,
and that they are interested in giving back their changes.
Justin Richer wrote:
* A somewhat rewritten Theme engine to replace the horribly incomplete
one found in 2.5. While this is not really an issue for GForge, many of
our other modules depend on some new themeable functions in this
infrastructure. We're going to have to work out exactly what needs to be
pulled and what needs to be dropped, as I don't think anyone is
particularly in the mood for completely rewriting the GForge theme
system (if you are, please speak up! :).
Yes, themes in GF3 are vastly cleaned up and pretty sane. There may be
some things you can improve on. If you have some functions to add to the
system, we'll be interested no doubt.
* A fully customizeable Role-Based Access Control system. All projects
have a number of Roles which individual developers may be assigned to
upon being added to the group. Each role has a set of privileges for
each tool, which can be set to Read, Write, or Admin by a project
administrator. All projects get a default of four pre-defined roles:
Administrator, Member, Logged-In (member of site but not of project),
and Guest (no logged in account at all). A project administrator does
have the option, though, of creating any new roles for further
granularity. Our implementation is *very* heavily tied into the 2.5
framework, so a near total reimplementation will be needed. But, I
believe that the concepts can be gleaned pretty readily and that with
GForge's increased granularity of thing we should be able to do this
one.
RBAC is good. Hopefully the permission object will be useful. I can't
remember if that stuff was in 2.5 or not. This hasn't changed much, if
at all, since 2.6x. It seems to me that if we can use the permission
object we have or re-factor it a little bit, you should be able to
extend it and make use of it for both RBAC and the existing system.
Since all calls go through the perms accessors, this should be
reasonably easy and clean to do.
RBAC should be optional. I discussed this on the list some time back and
not everyone was in favor of it.
* Integration of the Chora (http://www.horde.org/chora/) CVS viewing
framework into SourceForge. This negates the need for any kind of CVSWeb
or ViewCVS system external to SF. We needed it in order to secure the
CVS viewing of certain projects to only members of those projects. The
Chora viewer is an advanced tool written in PHP and on par with CVSWeb
and ViewCVS in most functions. We've even included the integration of
CVSGraph into this Chora system. In addition to the viewing
capabilities, we've added some capability to check-in files from a web
form into CVS, either individually or a directory at a time (using a ZIP
file as a transit).
There are several cvs browsers now with gforge. I haven't checked out
any of them besides cvsweb. I don't know if Chora is better or not than
these various new cvs browsers, but it can't hurt to add Chora support.
* CVS-backed Document Manager. We've done away with the traditional
Document Manager and used a CVS/Chora-backed module to create a system
with full document history and the capability to store and display
various document types, including binary files (PDFs and the like).
While this does exist to some extent in GForge already, backing it with
Chora and its viewer structures could make for a cleaner interface.
It sounds like the doc mgr should be pulled and turned into some sort of
module or plugin. We will want to keep the existing doc mgr as an
option, and I also want another option of having a webdav-based doc mgr
at some point.
* Enhanced FRS. We've rewritten the interface for managing released
files in SourceForge, and now allow for completely web-based control,
including upload. I must admit that I've yet to play with a lot of the
system as it exists in GForge, and I need to see how much overlap there
is and how much this part is really needed. Regarless, it's worlds
better than the interface that exists on SF 2.5, and maybe we can get
some of that into GForge as well.
We probably don't need this, as the FRS is greatly cleaned up and
simplified in gforge. The current system uses HTTP uploads, which is
sub-optimal for large files, but it sounds as if yours is the same way.
* Licence/Domain manager. We've written a system for dealing with
different licenses for people coming from different domains, as well as
filters allowing only registration from matching email addresses. This
is probably too specific to our own needs, but it's here if anyone's
interested in it.
There seems to be a broad interest in this. If you can make it some sort
of plugin or module, that would be great.
Tim