[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Debian-sf-devel] Future functionality questions...

From: Eric D Nielsen
Subject: [Debian-sf-devel] Future functionality questions...
Date: Thu, 27 Dec 2001 12:22:11 -0500

Dear all,

Justin Richer and myself have been working with the debain-sf 2.5 and 2.6
code for a while.  We've been submitting a few small patches/enhancements
in the past few weeks as we've gotten the site to work for us and our users.
However in the next few weeks we'll be make some rather large changes to
our installation to add a few features.  I plan to submit these back to 
debian-sf as there isn't a current "main sf baseline" to submit against and you
at debian-sf have been responsive about accepting patches.   As the stuff I'm
working on is rather large I wanted to give a heads up and ask a few questions:

First the questions:
1)  Will you be willing to accept non-bug related patches/enhancements?
2)  Are additions to the schema acceptable?  (Ie if my features require a 
new table or two is that fine?)
3)  What general guideline should I follow?  I'm planning that if a
installation choses not to use my features there should be no change from
the current installation.  Anything else?

Here's the feature set:
1) Improved Foundries:
   - Foundry of Foundries supported
   - Search searches both projects/foundries
   - Foundries have space for documents by default 
   - All administration is still web-based
   - Customizeable Foundry Classification (Top level classification)
   - Automated updating of foundry menus (both side bar menu and main "pane")
(These changes will require two new tables in the database to hold the
foundry Classification information and the possible many-to-many mapping of
foundry classes to foundries.  If Foundry Classification is not setup by the
site admins the top four bullets will still work, but the bottom two will not.
If it is turned on, extra options are adding to the select box on the 
site admin's project admin page, otherwise no change occurs on the regular

2) Security Granularity
   - Site can distinguish non-logged in/logged in/project member
   - Site can support above with PKI based authenication if given
   - Projects may be Public/Private/Hidden
     -- Projects may be hidden to non-logged in but Private to loggedin, etc
   - Tools may similarly be Public/Private/Hidden
   - Search knows to ignore hidden projects
   - Admin is web based.
(We're working on a site that requires more security than SF does and probably
more than many installs of debian-sf have.  I would understand if people don't
think this is paticularly useful to the community at large, but would still
want to make the code availible.  Again this will require extra tables in
the database, etc.)

If you would like me to post more information about these imporvements please
let me know what you'ld like to know.  The Imporved Foundry chunk is almost 
done.  The Security work is in the design phase at present but will proceed
quickly after that.

Happy Coding!
Eric Nielsen

reply via email to

[Prev in Thread] Current Thread [Next in Thread]