On Jun 4, 11:46 am, Robert C Corsaro <[EMAIL PROTECTED]> wrote:
> [EMAIL PROTECTED] wrote:
> > On Jun 4, 10:23 am, [EMAIL PROTECTED] wrote:
> >> Hi all.
>
> >> Ok, I have played with trac a bit, and some other supporting tools and
> >> plugins, etc.  I managed to get my hands on a server to "properly"
> >> host it on for our use internally.  The upper IT folks just refuse to
> >> give us an outward facing server.  So all of our outsources, will get
> >> vpn, or onsite access only, bummer, but a small step in the right
> >> direction.
>
> >> That said, the server we are getting is running windows.  I have seen/
> >> browsed the "on windows" wikis out there, and all seems good.  here is
> >> what I "hope" to run, and really just need to know if there are any
> >> "gotchas" I need to know about ahead of time.  I also will have admin
> >> rights on the box, but am not an IT admin anymore, so my windows
> >> server knowledge is, well, lame nowadays.
>
> >> anyway:
>
> >> * assumption: running Apache on windows.
> >> Trac
> >> Subversion
> >> probably php and all that jazz, although, at this moment, I have no
> >> need for it.
> >> the following plugins I am hoping to go with:
> >> TimingAndEstimation
> >> TracIniAdmin
> >> TracAccountManager
> >> TracUserManagerPlugin
> >> XMLRPC plugin
> >> MasterTicketsPlugin
> >> and probably the black magic one.
>
> >> Will have custom workflow, and probably have a handler hook as I want
> >> to do some stuff behind the scenes on one of the transitions of the
> >> workflow.
>
> >> Ok, I am sure there are other I might want, or "NEED" but I KNOW I
> >> would like those.  That said I also "want" to do the following:
>
> >> Multi-project setup  1-4 active most likely, and eventually those
> >> become a  maintenance stage, so still around.
> >> I also "think" I would want to use windows authentication somehow (is
> >> that ldap?) access to the subversion and trac environments.  simply
> >> because outsources will be internal to the network, and may never
> >> actually access trac directly.  I envision a eclipse/mylan interface
> >> very possible to the subversion/trac data.  I also see direct
> >> subversion access via subversion clients (TortiseSVN, svn command
> >> line, etc.) which may never actually utilize the trac DB).  I have no
> >> issue with requiring a second login to trac(via the nice web interface
> >> in one of the above plugins, I forget which one), just not sure if it
> >> is needed.  If there are other tools/plugins you think will make this
> >> objective go more smoothly, great, I can use that too, please let me
> >> know.  Things like TracMetrix etc. I might want to use, etc.
> >> Basically, I need to manage multiple projects, which are managed by
> >> multiple people, who manage multiple sources/levels of access. :D  All
> >> on bleeping windows servers....with no external facing web access....
>
> >> I think it's just the run of the mill TracOnWindows/Advanced path, but
> >> was  looking for insight.
>
> >> oh, yes, I personally prefer python 2.5, but seems like Apache needs
> >> 2.4, is that correct?  Anyone tried the windows bitNami installer?
> >> that would work too.  etc.
>
> >> I will try to really document well as I go, a future version of this
> >> email from others is not needed in the mailing list.
>
> >> Thanks.
>
> > I also forgot.  Some devs need access to multiple project environments
> > (subversion and trac) and some need to be restricted/redirected to the
> > project they know about.  We don't want some sources to even know
> > about the others.  I have no issue added each individual 1 by to to
> > each project that is appropriate, but I would like to grant access to
> > the "project list" or top-level to individuals with multi-project
> > access so they may navigate from a top level if they so choose.
> > "ideally" it would only show the projects they actually have access
> > to, but practically will not be needed for my purposes.  They will
> > either be able to see only 1 project, or them all.  While they may not
> > have rights to do anything in them all (read only, for example), that
> > is easily managed at the per project level.  See now, I just made it
> > more complicated, and just out of my grasp for implementing without a
> > little hand holding....
>
> We have worked out a secure solution with OForge[1].  We have two layers
> of authorization.  The first is site wide and the second is per project.
>   We do not yet have a way to redirect single project users to their
> projects, which is a problem.  If they don't have the URL right, they
> get an auth error.  Our needs are close to yours, our single projects
> clients shouldn't even know other projects exist.
>
> [1]http://code.optaros.com/trac/oforge

While potentially helpful, I don't see us using Oforge as:  it's not
ready or documented, I don't want to build all the parts from source,
and it seems like it won't be a windows server solution without a lot
of work as some of the components seem to be Linux only, or heavily
leaning (maybe I am wrong here).  And on a personal note, seems a
little java centric, but that could just be me.  It is also a little
more than I need at this point.  I currently will be the trac/
subversion "admin" but I will ultimately get to offload all that IT
crap (tm) to those that know what they are doing.  I am just the
guinea pig trying to drive the change, and therefor just really want
an "out of the box" solution that is as close to what I need as
possible.  While Oforge seems, in theory out of the box, there is a
LOT more than I need, and that is just more I need to admin.  I
wouldn't mind a link to how you accomplished this one need if you have
it however.

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "Trac 
Users" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/trac-users?hl=en
-~----------~----~----~----~------~----~------~--~---

Reply via email to