Mailing List Archive: Trac: Users

VCS hook control from Trac web admin?

Index | Next | Previous | View Threaded

magnus at therning

Jan 22, 2012, 10:34 AM

Post #1 of 19 (720 views)
Permalink

VCS hook control from Trac web admin?

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.

I thought I'd ask before I invest too much time in such a plugin
myself.

/M

--
Magnus Therning OpenPGP: 0xAB4DFBA4
email: magnus [at] therning jabber: magnus [at] therning
twitter: magthe http://therning.org/magnus

I invented the term Object-Oriented, and I can tell you I did not have
C++ in mind.
-- Alan Kay

[^1]: http://trac-hacks.org/wiki/TracSvnHooksPlugin

olemis at gmail

Jan 23, 2012, 5:48 AM

Post #2 of 19 (694 views)
Permalink

Re: VCS hook control from Trac web admin? [In reply to]

Hi !

On Sun, Jan 22, 2012 at 1:34 PM, Magnus Therning <magnus [at] therning> 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 [1]_

- 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 ?
- Target OS ?
- 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 ;) ?
- maybe you might want to add support in there for Git ;)
- maybe more later ... ;)

> I thought I'd ask before I invest too much time in such a plugin
> myself.
>

wise decision afaict
;)

.. [1] RepositoryHookSystemPlugin @ t.h.o
(http://trac-hacks.org/wiki/RepositoryHookSystemPlugin)

--
Regards,

Olemis

Facebook => http://www.facebook.com/olemis
Twitter => http://www.twitter.com/olemislc (@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 trac-users [at] googlegroups
To unsubscribe from this group, send email to trac-users+unsubscribe [at] googlegroups
For more options, visit this group at http://groups.google.com/group/trac-users?hl=en.

magnus at therning

Jan 25, 2012, 4:23 AM

Post #3 of 19 (691 views)
Permalink

Re: VCS hook control from Trac web admin? [In reply to]

On Mon, Jan 23, 2012 at 14:48, Olemis Lang <olemis [at] gmail> wrote:
> Hi !
>
> On Sun, Jan 22, 2012 at 1:34 PM, Magnus Therning <magnus [at] therning> 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 [1]_
>
> - 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.

> - Target OS ?

Linux

> - 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.

> - 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.

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
allow. (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. 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. 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. 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. The relationship between
system-admin and repo-admins on github mirrors the relationship
between system-admin and trac-admins in our organisation.

/M

--
Magnus Therning OpenPGP: 0xAB4DFBA4
email: magnus [at] therning jabber: magnus [at] therning
twitter: magthe http://therning.org/magnus

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

debacle at debian

Jan 25, 2012, 5:48 AM

Post #4 of 19 (694 views)
Permalink

Re: VCS hook control from Trac web admin? [In reply to]

Quoting "Magnus Therning" <magnus [at] therning>:
> 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
> allow. (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. 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. :)

Just to be sure: Does your Trac run under uid 0 (root)?
This would be completely unacceptable, of course. If Trac
runs as its own, separated user, the shell scripts still
can do harm, but e.g. not kill the system.

Uploading plugins can be easily prohibited by setting the
plugin dir to 555, very simple. Btw. plugins are only stored
in the plugins dir and cannot access data, that the trac
user (hopefully not root/0) is not allowed to access.

Cheers

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

olemis at gmail

Jan 25, 2012, 6:20 AM

Post #5 of 19 (699 views)
Permalink

Re: VCS hook control from Trac web admin? [In reply to]

On Wed, Jan 25, 2012 at 7:23 AM, Magnus Therning <magnus [at] therning> wrote:
>
> On Mon, Jan 23, 2012 at 14:48, Olemis Lang <olemis [at] gmail> wrote:
> > Hi !
> >
> > On Sun, Jan 22, 2012 at 1:34 PM, Magnus Therning <magnus [at] therning> 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 [1]_
> >
> > - 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 ?
>
> Linux
>

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 [2]_ (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.
>

common case
;)
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
> allow.

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
itself .
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 [3]_ . afaicr , in Bb you could
even build your own hooks (a.k.a. brokers) somehow ... let me check
where is it ? ... yep [4]_
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 [1]_ 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 .

.. [1] webadmin interface for the SVN post-commit hook for
RepositoryHookSystemPlugin
   (http://trac-hacks.org/attachment/wiki/RepositoryHookSystemPlugin/screenshot.png)

.. [2] Olemis' patch queue for
http://trac-hacks.org/wiki/RepositoryHookSystemPugin
   (https://bitbucket.org/olemis/trac-repositoryhooksystem-mq)

.. [3] Managing bitbucket Services
   (http://confluence.atlassian.com/display/BITBUCKET/Managing+bitbucket+Services)

.. [4] Writing Brokers for bitbucket
   (http://confluence.atlassian.com/display/BITBUCKET/Writing+Brokers+for+bitbucket)

--
Regards,

Olemis

Facebook => http://www.facebook.com/olemis
Twitter => http://www.twitter.com/olemislc (@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 trac-users [at] googlegroups
To unsubscribe from this group, send email to trac-users+unsubscribe [at] googlegroups
For more options, visit this group at http://groups.google.com/group/trac-users?hl=en.

olemis at gmail

Jan 25, 2012, 6:31 AM

Post #6 of 19 (688 views)
Permalink

Re: VCS hook control from Trac web admin? [In reply to]

On Wed, Jan 25, 2012 at 9:20 AM, Olemis Lang <olemis [at] gmail> wrote:
> On Wed, Jan 25, 2012 at 7:23 AM, Magnus Therning <magnus [at] therning> wrote:
>> On Mon, Jan 23, 2012 at 14:48, Olemis Lang <olemis [at] gmail> wrote:
>> > Hi !
>> >
>> > On Sun, Jan 22, 2012 at 1:34 PM, Magnus Therning <magnus [at] therning> wrote:
>>
[...]
>>
>> 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 [3]_ . afaicr , in Bb you could
> even build your own hooks (a.k.a. brokers) somehow ... let me check
> where is it ? ... yep [4]_
> needless to say I <3 Bb ;) . It's a pythonic-ly djang-ish thingy :)
>
[...]
>
> .. [3] Managing bitbucket Services
>    (http://confluence.atlassian.com/display/BITBUCKET/Managing+bitbucket+Services)
>
> .. [4] Writing Brokers for bitbucket
>    (http://confluence.atlassian.com/display/BITBUCKET/Writing+Brokers+for+bitbucket)
>

now that I was able to breath ... maybe it will be a good idea to
implement some adapters (i.e. Trac components implementing
IRepositoryHookSubscriber [5]_ ) so as to be able to reuse Bb brokers
in there ... though it's a crazy (1 minute old) idea at the moment ,
that maybe interesting . Nonetheless I'm not aware of the implications
yet .

.. [5] IRepositoryHookSubscriber
   (http://trac-hacks.org/browser/repositoryhooksystemplugin/0.11/repository_hook_system/interface.py)

--

Regards,

Olemis

Facebook => http://www.facebook.com/olemis
Twitter => http://www.twitter.com/olemislc (@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

Featured article : Identificando números primos con expresión regular en Perl
http://feedproxy.google.com/~r/simelo-news/~3/BHr859OSndo/identificando-numeros-primos-con.html
Tweet: RT @WANdisco How you can add #uTest to #uberSVN...
http://t.co/SCUhNd6B #fb
Follow @olemislc Reply Retweet   12:35 Jan-20
  Get this email app!
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 trac-users [at] googlegroups
To unsubscribe from this group, send email to trac-users+unsubscribe [at] googlegroups
For more options, visit this group at http://groups.google.com/group/trac-users?hl=en.

magnus at therning

Jan 25, 2012, 6:36 AM

Post #7 of 19 (686 views)
Permalink

Re: VCS hook control from Trac web admin? [In reply to]

On Wed, Jan 25, 2012 at 14:48, W. Martin Borgert <debacle [at] debian> wrote:
> Quoting "Magnus Therning" <magnus [at] therning>:
>>
>> 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
>> allow. (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. 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. :)
>
> Just to be sure: Does your Trac run under uid 0 (root)?
> This would be completely unacceptable, of course. If Trac
> runs as its own, separated user, the shell scripts still
> can do harm, but e.g. not kill the system.
>
> Uploading plugins can be easily prohibited by setting the
> plugin dir to 555, very simple. Btw. plugins are only stored
> in the plugins dir and cannot access data, that the trac
> user (hopefully not root/0) is not allowed to access.

*I* don't run the server, and I enjoy being able to upload plugins, so
I will assume our system admins are competent enough to not run
Apache/Trac/whatever as root, and I will *not* tell them how to
prohibit uploading plugins. ;)

/M

--
Magnus Therning OpenPGP: 0xAB4DFBA4
email: magnus [at] therning jabber: magnus [at] therning
twitter: magthe http://therning.org/magnus

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

olemis at gmail

Jan 25, 2012, 6:46 AM

Post #8 of 19 (684 views)
Permalink

Re: VCS hook control from Trac web admin? [In reply to]

On Wed, Jan 25, 2012 at 9:36 AM, Magnus Therning <magnus [at] therning> wrote:
> On Wed, Jan 25, 2012 at 14:48, W. Martin Borgert <debacle [at] debian> wrote:
>> Quoting "Magnus Therning" <magnus [at] therning>:
>>>
>>> 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
>>> allow. (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. 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. :)
>>
>> Just to be sure: Does your Trac run under uid 0 (root)?
>> This would be completely unacceptable, of course. If Trac
>> runs as its own, separated user, the shell scripts still
>> can do harm, but e.g. not kill the system.
>>
>> Uploading plugins can be easily prohibited by setting the
>> plugin dir to 555, very simple. Btw. plugins are only stored
>> in the plugins dir and cannot access data, that the trac
>> user (hopefully not root/0) is not allowed to access.
>
> *I* don't run the server, and I enjoy being able to upload plugins, so
> I will assume our system admins are competent enough to not run
> Apache/Trac/whatever as root, and I will *not* tell them how to
> prohibit uploading plugins. ;)
>

side-note : IMO there's no reason to pay special attention to prevent
plugin installation (as you mentioned in previous comments ;) inside
specific plugins code. IMO that should be a more higher level decision
, and is a responsibility of server admins (i.e. using available setup
/ configuration options & tools at hand )

just my $0.02 about this subject ;)

--

Regards,

Olemis

Facebook => http://www.facebook.com/olemis
Twitter => http://www.twitter.com/olemislc (@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

Featured article : Identificando números primos con expresión regular en Perl
http://feedproxy.google.com/~r/simelo-news/~3/BHr859OSndo/identificando-numeros-primos-con.html
Tweet: RT @WANdisco How you can add #uTest to #uberSVN...
http://t.co/SCUhNd6B #fb
Follow @olemislc Reply Retweet 12:35 Jan-20
Get this email app!
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 trac-users [at] googlegroups
To unsubscribe from this group, send email to trac-users+unsubscribe [at] googlegroups
For more options, visit this group at http://groups.google.com/group/trac-users?hl=en.

debacle at debian

Jan 25, 2012, 6:51 AM

Post #9 of 19 (699 views)
Permalink

Re: VCS hook control from Trac web admin? [In reply to]

Quoting "Magnus Therning" <magnus [at] therning>:
> I will *not* tell them how to
> prohibit uploading plugins. ;)

Let's hope they don't read this mailing list :~)

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

magnus at therning

Jan 25, 2012, 2:21 PM

Post #10 of 19 (689 views)
Permalink

Re: VCS hook control from Trac web admin? [In reply to]

On Wed, Jan 25, 2012 at 09:20:11AM -0500, Olemis Lang wrote:
> On Wed, Jan 25, 2012 at 7:23 AM, Magnus Therning <magnus [at] therning> wrote:

> common case
> ;)
> you should have more control over this once multi-project support will
> be ready ... but it's not yet

Would an option be to make it per-repository rather than per-project?
I guess the config would be slightly more complicated, but at the same
time it might be easier to grasp what's going on as well as slightly
more configurable.

>> 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 allow.
>
>
> 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 ;)

Then maybe I'm just confused by the screen-shot, it gives the
impression that it's possible to write bash code to be executed on the
hook.

>> 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 [1]_ but without
> the possibility to edit hook script directly (i.e. only what u see
> below "Listeners on this hook" section) ?

Ah, I did miss that little detail earlier. Good that you pointed it
out. Indeed, it's only that last bit I'd be interested in. I can see
a use for making hooks fully editable through the web admin, but it'd
be nice if a system-admin could turn it off somehow.

>> 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 ?

Yes, I'm starting to agree with you :)

/M

--
Magnus Therning OpenPGP: 0xAB4DFBA4
email: magnus [at] therning jabber: magnus [at] therning
twitter: magthe http://therning.org/magnus

Most software today is very much like an Egyptian pyramid with
millions of bricks piled on top of each other, with no structural
integrity, but just done by brute force and thousands of slaves.
-- Alan Kay

olemis at gmail

Jan 26, 2012, 6:46 AM

Post #11 of 19 (665 views)
Permalink

Re: VCS hook control from Trac web admin? [In reply to]

On Wed, Jan 25, 2012 at 5:21 PM, Magnus Therning <magnus [at] therning> wrote:
> On Wed, Jan 25, 2012 at 09:20:11AM -0500, Olemis Lang wrote:
> > On Wed, Jan 25, 2012 at 7:23 AM, Magnus Therning <magnus [at] therning> wrote:
>
> > common case
> > ;)
> > you should have more control over this once multi-project support will
> > be ready ... but it's not yet
>
> Would an option be to make it per-repository rather than per-project?

hook configuration ? maybe this is a good idea to be included in the
plugin for Trac>=0.12 .
nonetheless afaicr above I was talking about just the trac-admin vs
sys-admin scenario .

>
> I guess the config would be slightly more complicated, but at the same
> time it might be easier to grasp what's going on as well as slightly
> more configurable.
>

I'm guessing there's a chance for both choices to be appropriate under
certain circumstances . IMO it'd be nice to figure out what approaches
may be considered to add support for >=0.12 and compare each one of
the side-by-side . Hence I've created this page [1]_

> >> 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 allow.
> >
> > 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 ;)
>
> Then maybe I'm just confused by the screen-shot, it gives the
> impression that it's possible to write bash code to be executed on the
> hook.
>

yes and no ;)
In the case of SVN the plugin adds one line consisting of the command
to be invoked so as to trigger execution of IRepositoryHookSubscriber
instances . The textarea in the admin panel is aimed at editing that
single command (afaicr e.g. due to the fact that path to python
executable may be hard to determine under certain circumstances ;) .
However , as you mentioned before **now** it's possible to add
anything else in there ;)

>
> >> 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 [1]_ but without
> > the possibility to edit hook script directly (i.e. only what u see
> > below "Listeners on this hook" section) ?
>
> Ah, I did miss that little detail earlier. Good that you pointed it
> out. Indeed, it's only that last bit I'd be interested in.

;)

>
> I can see
> a use for making hooks fully editable through the web admin, but it'd
> be nice if a system-admin could turn it off somehow.
>

Like I mentioned before , if your trac-admins have TRAC_ADMIN
privileges then it's hard to implement these kinds of things ... at
least while there's no implementation for multi-project support . Once
this will be ready the distinction between TRAC_ADMIN and
PROJECT_ADMIN should allow for managing these kinds of setups
;)

>
> >> 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 ?
>
> Yes, I'm starting to agree with you :)
>

;)

.. [1] Managing hooks in environments linked to multiple repositories
(http://trac-hacks.org/wiki/RepositoryHookSystemPlugin/MultipleRepositorySupport)

--
Regards,

Olemis

Facebook => http://www.facebook.com/olemis
Twitter => http://www.twitter.com/olemislc (@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

Featured article : Identificando números primos con expresión regular en Perl
http://feedproxy.google.com/~r/simelo-news/~3/BHr859OSndo/identificando-numeros-primos-con.html
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 trac-users [at] googlegroups
To unsubscribe from this group, send email to trac-users+unsubscribe [at] googlegroups
For more options, visit this group at http://groups.google.com/group/trac-users?hl=en.

magnus at therning

Feb 21, 2012, 5:22 AM

Post #12 of 19 (584 views)
Permalink

Re: VCS hook control from Trac web admin? [In reply to]

I've not had much time to look into this lately, but I have a question
about the basic design. Correct me if I'm wrong, but your design
seems to call for a very simple hook to be placed in the VCS hook dir
(e.g. ${svn-repo-dir}/) which then is invoked by the VCS. This hook
then calls back into Trac and implementors of
IRepositoryChangeListener are told about the change, and they call
into all IRepositoryHookSubscribers. Is that correct?

If my understanding is correct, what is the use-case behind this trip
back into Trac and added complexity?

Why not just drop a script into the VCS hook dir which then executes
"functions" located in a well-known place (e.g.
${svn-repo-dir}/functions/)?
If each "function" is an executable file that would be very simple to
do. The admin page could then allow activation of functions per
repository. Functions are packaged with the plugin, giving the
system-admin full control over what is available to trac-admins.

/M

--
Magnus Therning OpenPGP: 0xAB4DFBA4
email: magnus [at] therning jabber: magnus [at] therning
twitter: magthe http://therning.org/magnus

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

olemis at gmail

Feb 21, 2012, 5:41 AM

Post #13 of 19 (587 views)
Permalink

Re: VCS hook control from Trac web admin? [In reply to]

On Tue, Feb 21, 2012 at 8:22 AM, Magnus Therning <magnus [at] therning> wrote:
> I've not had much time to look into this lately, but I have a question
> about the basic design. Correct me if I'm wrong, but your design
> seems to call for a very simple hook to be placed in the VCS hook dir
> (e.g. ${svn-repo-dir}/) which then is invoked by the VCS. This hook
> then calls back into Trac and implementors of
> IRepositoryChangeListener are told about the change, and they call
> into all IRepositoryHookSubscribers. Is that correct?
>
> If my understanding is correct, what is the use-case behind this trip
> back into Trac and added complexity?
>

quick reply : the idea is to implement hooks as Trac components . This
also means options , database access , ... will be there for you .

- `IRepositoryChangeListener` is some kind of abstraction layer
  handling VCS-specific features to satisfy a uniform interface ...
- ... for `IRepositoryHookSubscribers` which implement the actual
  hook behavior .

> Why not just drop a script into the VCS hook dir which then executes
> "functions" located in a well-known place (e.g.
> ${svn-repo-dir}/functions/)?

... maybe ... but different VCS (svn, hg , git ..) deal with hook
context & activation in many different ways . So you **should** need
an intermediate layer to bind Trac-specific VCS resources (e.g.
changesets) and hook context information , so as to make those
«functions» work *for every* VCS supported by Trac .

> If each "function" is an executable file that would be very simple to
> do. The admin page could then allow activation of functions per
> repository. Functions are packaged with the plugin, giving the
> system-admin full control over what is available to trac-admins.
>

the same for Trac components ... isn't it ?

--
Regards,

Olemis

Facebook => http://www.facebook.com/olemis
Twitter => http://www.twitter.com/olemislc (@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

Featured article : Identificando números primos con expresión regular en Perl
http://feedproxy.google.com/~r/simelo-news/~3/BHr859OSndo/identificando-numeros-primos-con.html
Tweet: yo no puedo creer q haya pasado inadvertido el 1/2/12 12:12 ...
@elainediaz2003 no dijo na' ... OMG ! ... much more coming soon ;) #fb
Follow @olemislc Reply Retweet   12:59 Feb-01
  Get this email app!
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 trac-users [at] googlegroups
To unsubscribe from this group, send email to trac-users+unsubscribe [at] googlegroups
For more options, visit this group at http://groups.google.com/group/trac-users?hl=en.

magnus at therning

Feb 21, 2012, 6:27 AM

Post #14 of 19 (590 views)
Permalink

Re: VCS hook control from Trac web admin? [In reply to]

On Tue, Feb 21, 2012 at 14:41, Olemis Lang <olemis [at] gmail> wrote:
> On Tue, Feb 21, 2012 at 8:22 AM, Magnus Therning <magnus [at] therning> wrote:
>> I've not had much time to look into this lately, but I have a question
>> about the basic design. Correct me if I'm wrong, but your design
>> seems to call for a very simple hook to be placed in the VCS hook dir
>> (e.g. ${svn-repo-dir}/) which then is invoked by the VCS. This hook
>> then calls back into Trac and implementors of
>> IRepositoryChangeListener are told about the change, and they call
>> into all IRepositoryHookSubscribers. Is that correct?
>>
>> If my understanding is correct, what is the use-case behind this trip
>> back into Trac and added complexity?
>
> quick reply : the idea is to implement hooks as Trac components . This
> also means options , database access , ... will be there for you .
>
> - `IRepositoryChangeListener` is some kind of abstraction layer
> handling VCS-specific features to satisfy a uniform interface ...
> - ... for `IRepositoryHookSubscribers` which implement the actual
> hook behavior .

Good, then it sounds like I've understood your design well enough :)

>> Why not just drop a script into the VCS hook dir which then executes
>> "functions" located in a well-known place (e.g.
>> ${svn-repo-dir}/functions/)?
>
> ... maybe ... but different VCS (svn, hg , git ..) deal with hook
> context & activation in many different ways . So you **should** need
> an intermediate layer to bind Trac-specific VCS resources (e.g.
> changesets) and hook context information , so as to make those
> «functions» work *for every* VCS supported by Trac .

Except that *I* didn't have any functions in mind that actually need
Trac-specific VCS resources. I thought of stuff like

- send email on commit
- send twitter on commit
- tickle a CI server on commit
- ...

>> If each "function" is an executable file that would be very simple to
>> do. The admin page could then allow activation of functions per
>> repository. Functions are packaged with the plugin, giving the
>> system-admin full control over what is available to trac-admins.
>
> the same for Trac components ... isn't it ?

Except that writing a Trac component is a bit more involved than
writing a script (in any language you are comfortable with) which
takes a well-specified set of arguments on the command line.

Also, the configuration is probably somewhat more involved if hook
functions are allowed to come as separate Trac plugins.

/M

--
Magnus Therning OpenPGP: 0xAB4DFBA4
email: magnus [at] therning jabber: magnus [at] therning
twitter: magthe http://therning.org/magnus

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

olemis at gmail

Feb 21, 2012, 6:56 AM

Post #15 of 19 (585 views)
Permalink

Re: VCS hook control from Trac web admin? [In reply to]

On Tue, Feb 21, 2012 at 9:27 AM, Magnus Therning <magnus [at] therning> wrote:
> On Tue, Feb 21, 2012 at 14:41, Olemis Lang <olemis [at] gmail> wrote:
>> On Tue, Feb 21, 2012 at 8:22 AM, Magnus Therning <magnus [at] therning> wrote:
>>> I've not had much time to look into this lately, but I have a question
>>> about the basic design. Correct me if I'm wrong, but your design
>>> seems to call for a very simple hook to be placed in the VCS hook dir
>>> (e.g. ${svn-repo-dir}/) which then is invoked by the VCS. This hook
>>> then calls back into Trac and implementors of
>>> IRepositoryChangeListener are told about the change, and they call
>>> into all IRepositoryHookSubscribers. Is that correct?
>>>
>>> If my understanding is correct, what is the use-case behind this trip
>>> back into Trac and added complexity?
>>
>> quick reply : the idea is to implement hooks as Trac components . This
>> also means options , database access , ... will be there for you .
>>
>> - `IRepositoryChangeListener` is some kind of abstraction layer
>> handling VCS-specific features to satisfy a uniform interface ...
>> - ... for `IRepositoryHookSubscribers` which implement the actual
>> hook behavior .
>
> Good, then it sounds like I've understood your design well enough :)
>

;)

>>> Why not just drop a script into the VCS hook dir which then executes
>>> "functions" located in a well-known place (e.g.
>>> ${svn-repo-dir}/functions/)?
>>
>> ... maybe ... but different VCS (svn, hg , git ..) deal with hook
>> context & activation in many different ways . So you **should** need
>> an intermediate layer to bind Trac-specific VCS resources (e.g.
>> changesets) and hook context information , so as to make those
>> «functions» work *for every* VCS supported by Trac .
>
> Except that *I* didn't have any functions in mind that actually need
> Trac-specific VCS resources. I thought of stuff like
>
> - send email on commit
> - send twitter on commit
> - tickle a CI server on commit
> - ...
>

... if you plan to use commit message , author , ... etc ... then
you'll need access to changeset information in hook context , and then
u'll need the Trac changeset as an abstraction so as to make «the
whole thing» work for any VCS ;)

>>> If each "function" is an executable file that would be very simple to
>>> do. The admin page could then allow activation of functions per
>>> repository. Functions are packaged with the plugin, giving the
>>> system-admin full control over what is available to trac-admins.
>>
>> the same for Trac components ... isn't it ?
>
> Except that writing a Trac component is a bit more involved than
> writing a script (in any language you are comfortable with) which
> takes a well-specified set of arguments on the command line.
>

In this case , the way to go should be to write a *single* Trac
component *once* , specify an option for the scripts path ... a few
more things (maybe) and there u have it !
Or maybe configure them directly ... using VCS-specific hook config
mechanisms . I mean you have a good reason to integrate this with Trac
, isn't it ?

> Also, the configuration is probably somewhat more involved if hook
> functions are allowed to come as separate Trac plugins.
>

Configuration is basically , install & enable plugin , activate hook
in hook admin panel , set parameters . You are ready to go ;)

--
Regards,

Olemis

Facebook => http://www.facebook.com/olemis
Twitter => http://www.twitter.com/olemislc (@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

Featured article : Identificando números primos con expresión regular en Perl
http://feedproxy.google.com/~r/simelo-news/~3/BHr859OSndo/identificando-numeros-primos-con.html
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 trac-users [at] googlegroups
To unsubscribe from this group, send email to trac-users+unsubscribe [at] googlegroups
For more options, visit this group at http://groups.google.com/group/trac-users?hl=en.

magnus at therning

Feb 21, 2012, 1:38 PM

Post #16 of 19 (589 views)
Permalink

Re: VCS hook control from Trac web admin? [In reply to]

On Tue, Feb 21, 2012 at 09:56:25AM -0500, Olemis Lang wrote:
> On Tue, Feb 21, 2012 at 9:27 AM, Magnus Therning <magnus [at] therning> wrote:
>> On Tue, Feb 21, 2012 at 14:41, Olemis Lang <olemis [at] gmail> wrote:
>>> On Tue, Feb 21, 2012 at 8:22 AM, Magnus Therning <magnus [at] therning> wrote:

>>>> Why not just drop a script into the VCS hook dir which then executes
>>>> "functions" located in a well-known place (e.g.
>>>> ${svn-repo-dir}/functions/)?
>>>
>>> ... maybe ... but different VCS (svn, hg , git ..) deal with hook
>>> context & activation in many different ways . So you **should**
>>> need an intermediate layer to bind Trac-specific VCS resources
>>> (e.g. changesets) and hook context information , so as to make
>>> those «functions» work *for every* VCS supported by Trac .
>>
>> Except that *I* didn't have any functions in mind that actually
>> need Trac-specific VCS resources. I thought of stuff like
>>
>> - send email on commit
>> - send twitter on commit
>> - tickle a CI server on commit
>> - ...
>
> ... if you plan to use commit message , author , ... etc ... then
> you'll need access to changeset information in hook context , and
> then u'll need the Trac changeset as an abstraction so as to make
> «the whole thing» work for any VCS ;)

Well, I can see it could be useful to have such an abstraction for
some functions, but far from all of them.

>>>> If each "function" is an executable file that would be very
>>>> simple to do. The admin page could then allow activation of
>>>> functions per repository. Functions are packaged with the
>>>> plugin, giving the system-admin full control over what is
>>>> available to trac-admins.
>>>
>>> the same for Trac components ... isn't it ?
>>
>> Except that writing a Trac component is a bit more involved than
>> writing a script (in any language you are comfortable with) which
>> takes a well-specified set of arguments on the command line.
>
> In this case , the way to go should be to write a *single* Trac
> component *once* , specify an option for the scripts path ... a few
> more things (maybe) and there u have it ! Or maybe configure them
> directly ... using VCS-specific hook config mechanisms . I mean you
> have a good reason to integrate this with Trac, isn't it ?

Having a single plugin that basically just deals with configuration of
VCS (a replacement for the default RepositoryAdminPanel class), and
the functions are put in as resources in the plugin's Egg. Adding
further functions is done by adding a shell script (or something else
that's executable) to the Egg. That is, adding a function doesn't
require writing another Trac plugin.

>> Also, the configuration is probably somewhat more involved if hook
>> functions are allowed to come as separate Trac plugins.
>
> Configuration is basically , install & enable plugin , activate hook
> in hook admin panel , set parameters . You are ready to go ;)

I see the *implementation* of the configuration to be more
complicated. I think there are good reasons to be able to enable a
function for a subset of the VCS repos only. I also think there are
good reasons to be able to configure the functions with different
parameters for each VCS repo. The options I see then is that each
function comes with its own admin page, or that each function can hook
into an admin page. Both of these are more involved.

I should probably point out that I don't think yours is a bad design,
I'm just trying to discern whether the complexity compared to a
simpler (and less capable) design really is worth it ;)

/M

--
Magnus Therning OpenPGP: 0xAB4DFBA4
email: magnus [at] therning jabber: magnus [at] therning
twitter: magthe http://therning.org/magnus

Most software today is very much like an Egyptian pyramid with
millions of bricks piled on top of each other, with no structural
integrity, but just done by brute force and thousands of slaves.
-- Alan Kay

olemis at gmail

Feb 22, 2012, 8:51 AM

Post #17 of 19 (579 views)
Permalink

Re: VCS hook control from Trac web admin? [In reply to]

On Tue, Feb 21, 2012 at 4:38 PM, Magnus Therning <magnus [at] therning> wrote:
> On Tue, Feb 21, 2012 at 09:56:25AM -0500, Olemis Lang wrote:
>> On Tue, Feb 21, 2012 at 9:27 AM, Magnus Therning <magnus [at] therning> wrote:
>>> On Tue, Feb 21, 2012 at 14:41, Olemis Lang <olemis [at] gmail> wrote:
>>>> On Tue, Feb 21, 2012 at 8:22 AM, Magnus Therning <magnus [at] therning> wrote:
>
[...]
>
>>> Also, the configuration is probably somewhat more involved if hook
>>> functions are allowed to come as separate Trac plugins.
>>
>> Configuration is basically , install & enable plugin , activate hook
>> in hook admin panel , set parameters . You are ready to go ;)
>
> I see the *implementation* of the configuration to be more
> complicated. I think there are good reasons to be able to enable a
> function for a subset of the VCS repos only. I also think there are
> good reasons to be able to configure the functions with different
> parameters for each VCS repo.

I agree . All this is correct even if not available at the moment as
the plugin is design for 0.11 .
So basically it's a TODO
;)

> The options I see then is that each
> function comes with its own admin page, or that each function can hook
> into an admin page. Both of these are more involved.
>

I was thinking of doing something somehow different . Focus on an
scenario similar to Bitbucket . You have many repositories each one
having hooks admin page where you select «functions» to trigger and,
for each active «function» , specify parameters .

I don't see why we cannot implement something as simple as that ...
especially considering the fact that it's possible to do it the way we
want to (i.e. improve it if necessary , and let people do things their
own way by defining extension points ;)

> I should probably point out that I don't think yours is a bad design,
> I'm just trying to discern whether the complexity compared to a
> simpler (and less capable) design really is worth it ;)
>

I'll reply this part later today ...

--
Regards,

Olemis.

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

magnus at therning

Feb 22, 2012, 10:13 AM

Post #18 of 19 (584 views)
Permalink

Re: VCS hook control from Trac web admin? [In reply to]

On Wed, Feb 22, 2012 at 11:51:09AM -0500, Olemis Lang wrote:
> On Tue, Feb 21, 2012 at 4:38 PM, Magnus Therning <magnus [at] therning> wrote:
>> The options I see then is that each function comes with its own
>>admin page, or that each function can hook into an admin page. Both
>>of these are more involved.
>
> I was thinking of doing something somehow different . Focus on an
> scenario similar to Bitbucket . You have many repositories each one
> having hooks admin page where you select «functions» to trigger and,
> for each active «function» , specify parameters .
>
> I don't see why we cannot implement something as simple as that ...
> especially considering the fact that it's possible to do it the way
> we want to (i.e. improve it if necessary , and let people do things
> their own way by defining extension points ;)

Well, if there is a single page to administrate *all* «functions», but
the «functions» actually come in separate plugins, then each plugin
need to somehow hook into that single page. That's what I mean with
"each function can hook into an admin page" above. Not impossible,
but more complicated than if all «functions» are contained in a single
plugin.

/M

--
Magnus Therning OpenPGP: 0xAB4DFBA4
email: magnus [at] therning jabber: magnus [at] therning
twitter: magthe http://therning.org/magnus

Most software today is very much like an Egyptian pyramid with
millions of bricks piled on top of each other, with no structural
integrity, but just done by brute force and thousands of slaves.
-- Alan Kay

olemis at gmail

Feb 22, 2012, 10:48 AM

Post #19 of 19 (580 views)
Permalink

Re: VCS hook control from Trac web admin? [In reply to]

On Wed, Feb 22, 2012 at 1:13 PM, Magnus Therning <magnus [at] therning> wrote:
> On Wed, Feb 22, 2012 at 11:51:09AM -0500, Olemis Lang wrote:
> > On Tue, Feb 21, 2012 at 4:38 PM, Magnus Therning <magnus [at] therning> wrote:
>
> >> The options I see then is that each function comes with its own
> >>admin page, or that each function can hook into an admin page. Both
> >>of these are more involved.
> >
> > I was thinking of doing something somehow different . Focus on an
> > scenario similar to Bitbucket . You have many repositories each one
> > having hooks admin page where you select «functions» to trigger and,
> > for each active «function» , specify parameters .
> >
> > I don't see why we cannot implement something as simple as that ...
> > especially considering the fact that it's possible to do it the way
> > we want to (i.e. improve it if necessary , and let people do things
> > their own way by defining extension points ;)
>
> Well, if there is a single page to administrate *all* «functions», but
> the «functions» actually come in separate plugins, then each plugin
> need to somehow hook into that single page. That's what I mean with
> "each function can hook into an admin page" above. Not impossible,
> but more complicated than if all «functions» are contained in a single
> plugin.
>

Now I c your point . Maybe I didn't understand your idea in first place .
;)

--
Regards,

Olemis

Facebook => http://www.facebook.com/olemis
Twitter => http://www.twitter.com/olemislc (@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

Featured article : [svn r11148] XmlRpcPlugin: `wiki.getPageHTML()` now
supports wiki manipulators that can possibly modify the wiki text
content before rendering. With test.
http://feedproxy.google.com/~r/simelo-news/~3/jk0kgDl73ss/08d0967ae31a
Tweet: yo no puedo creer q haya pasado inadvertido el 1/2/12 12:12 ...
@elainediaz2003 no dijo na' ... OMG ! ... much more coming soon ;) #fb
Follow @olemislc Reply Retweet 12:59 Feb-01
Get this email app!
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 trac-users [at] googlegroups
To unsubscribe from this group, send email to trac-users+unsubscribe [at] googlegroups
For more options, visit this group at http://groups.google.com/group/trac-users?hl=en.

Index | Next | Previous | View Threaded

Interested in having your list archived? Contact Gossamer Threads