On Wed, Jan 25, 2012 at 7:23 AM, Magnus Therning <firstname.lastname@example.org> wrote: >
> On Mon, Jan 23, 2012 at 14:48, Olemis Lang <email@example.com> wrote:
> > Hi !
> > On Sun, Jan 22, 2012 at 1:34 PM, Magnus Therning <firstname.lastname@example.org> wrote:
> >> I've only found a plugin that allows editing of SVN hooks[^1], but it
> >> is unlikely to cut it in our organisation; having users editing
> >> scripts that are run on the server will not be well received by the
> >> system admins. So, is there some other plugin that gives the user
> >> some control (but not full) over the hooks, maybe something along the
> >> lines of how github handles hooks? Ideally it should also support
> >> both SVN and git.
> > ... well ... I'm the maintainer of RepositoryHookSystemPlugin _
> > - so far it works mostly in GNU/Linux i.e. better compatibility for
> > Windows is needed
> > - ... even if it's designed to support any type of VCS only SVN is actually
> > implemented at the moment , and I was thinking of adding support for Hg .
> > - it's written for 0.11
> > - in theory users should not be managing repository hooks, not even
> > doing any other
> > admin task (as they all require at least TRAC_ADMIN permission ;) , unless
> > something like multi-project support is to be used and some users manage a
> > project inside an environment .
> > so my Qs are :
> > - What's the target version of Trac ?
> 0.12 and later.
... well ... that been said , if you move forward this way then you
should also be interested (as I am ;) in adding support for Trac>=0.12
(which adds some extra-complexity e.g. multi-repos ;) . >
> > - Target OS ?
good ... though for Trac>=0.12 the underlying reason making it not to
work now in Windows should be gone (reduced ?)
> > - If I move its code to e.g. some Hg repository @ Bitbucket
> > would you consider using that plugin as starting point for
> > your work (rather than starting the whole thing from
> > scratch ;) ?
> Absolutely, but see my comment below.
btw ... check this out _ (please contact me in private to grant
your Bb user with write access to the patch queue ;) . We can hack a
little and work on patches in there so as to experiment for a while
without touching the main repos . If it turns out that something
useful and generic is built in there then I can request an «upgrade»
your status so as to to grant you with commit access to main repos ;) > > - maybe you might want to add support in there for Git ;)
> Yes, git is an important target for me in the medium term.
> Now to my slightly longer comment after reading about the plugin you
> pointed me to. First, there are two admins in the system, the
> system-admin (or root) who has full access to the machine, and
> trac-admins who has admin rights only on a Trac instance. Beyond this
> there are also trac-users. Do note that there are no system-users in
> our setup.
you should have more control over this once multi-project support will
be ready ... but it's not yet >
> They way I understand your plugin it would most likely not be
> acceptable in our environment. Having trac-admins write scripts that
> get executed on the server is not something the system-admin will
that's exactly the goal of the plugin , to implement components inside
a Trac environment so as to allow for hook customization but without
full access to VCS-specific hook machinery
> (This is in the name of security, and I know that there are
> other garage-door sized wholes already, like the ability for a
> trac-admin to upload any plugin.
... if you allow doing this then you have a more serious security
issue as this is something happening beyond the scope of the plugin
think about it this way : if you manage to prevent trac-admins from
uploading plugins (i.e. disable pluginadmin web panel) then only
installed Trac components (as determined by system-admins ;) will be
available in the admin GUI for trac-admins to choose from . I mean ,
plugin may be refactored to work this way. Specific hook extensions
should be implemented by somebody anyway, but only system-admins will
be able to install them in there ;) provided that trac-admin(s) don't
have direct access to the system (e.g. via ssh ) . >
> But hey, I'm not keen on trying to
> push through an obvious way for trac-admins to run code on the server
> by pointing out that there already is another, less obvious, way to do
> just that. Not when that other mechanism is so useful to me as a
> trac-admin. :)
> No what I'm envisioning is a plugin that works a lot like github's
> hook functions. On github a set of hook functions are available to
> the repo admin to choose from.
yes it's similar to Bitbucket as well _ . afaicr , in Bb you could
even build your own hooks (a.k.a. brokers) somehow ... let me check
where is it ? ... yep _
needless to say I <3 Bb ;) . It's a pythonic-ly djang-ish thingy :) >
> Which functions are available is
> controlled by the system-admin. A repo-admin then ticks the ones that
> she/he wants, with some configuration possible, like if a mail is to
> be sent on commit, where does it get sent, etc.
**similar** to what is displayed in this screenshot _ but without
the possibility to edit hook script directly (i.e. only what u see
below "Listeners on this hook" section) ? >
> This means the
> system-admin has full control of what code can possibly get run on the
> server, while the repo-admin can choose the functions that make sense
> for each repo.
> Adding a new function is a bit bureaucratic, but does
> allow the system-admin to stay in charge.
... if we put all the pieces mentioned above together then it should
be possible to achieve what u want ... isn't it ? > The relationship between
> system-admin and repo-admins on github mirrors the relationship
> between system-admin and trac-admins in our organisation.
... even if not exactly the same as your (and other people's)
system-admins vs trac-admins scenario **should be** a bit different as
compared with github & bitbucket scenarios , I guess .
I look forward to your reply .
..  webadmin interface for the SVN post-commit hook for
..  Olemis' patch queue for http://trac-hacks.org/wiki/RepositoryHookSystemPugin
..  Managing bitbucket Services
..  Writing Brokers for bitbucket
Facebook => http://www.facebook.com/olemis
Twitter => http://www.twitter.com/olemislc
Blog ES => http://simelo-es.blogspot.com
Blog EN => http://simelo-en.blogspot.com
Quora => http://www.quora.com/olemis
Youtube => http://youtube.com/user/greatsoftw
Get a signature like this. CLICK HERE.
You received this message because you are subscribed to the Google Groups "Trac Users" group.
To post to this group, send email to email@example.com.
To unsubscribe from this group, send email to firstname.lastname@example.org.
For more options, visit this group at http://groups.google.com/group/trac-users?hl=en.