bloodhound-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ryan Ollos <ryan.ol...@wandisco.com>
Subject Re: [Apache Bloodhound] #516: No ticket view permission for nightly build demo configuration
Date Fri, 31 May 2013 02:19:17 GMT
On Thu, May 9, 2013 at 12:46 PM, Olemis Lang <olemis@gmail.com> wrote:

> On 5/8/13, Gary Martin <gary.martin@wandisco.com> wrote:
> > On 08/05/13 18:06, Olemis Lang wrote:
> >> On 5/8/13, Gary Martin <gary.martin@wandisco.com> wrote:
> >>> On 08/05/13 16:15, Olemis Lang wrote:
> >>>> On 5/8/13, Gary Martin <gary.martin@wandisco.com> wrote:
> >> [...]
> >>>>> If it is, how does that allow me to add a resolution enum to a
> >>>>> product,
> >>>>> for example?
> >>>>>
> >>>> Product prefix = test
> >>>>
> >>>> {{{
> >>>> #!sh
> >>>>
> >> [...]
> >>>> Trac [/path/to/trac/env]> product admin test resolution add custom
> >>>> Trac [/path/to/trac/env]> product admin test resolution list
> >>>>
> >> [...]
> >>>> }}}
> >>>>
> >>> Fair enough. I didn't spot that in the list of commands. I obviously
> was
> >>> not looking hard enough.
> >>>
> >> JFTR the second part of the command (i.e. resolution ...) is
> >> «re-dispatched» to the target admin command handler but in product
> >> scope . Therefore help msg is generic Supported command list might be
> >> even different to global cmd list given the fact that component
> >> enable/disable rules in product scope might be different to global
> >> list .
> >>
> >> Therefore maybe it's ok to improve product admin cmd help docs ... or
> >> just add a reference to a wiki page clarifying its usage .
> >>
> >
> > It seems a reasonable solution. I might expect something like "product
> > admin [product] help" or "product help admin [product]" for the purpose
> > of listing the available product admin commands.
> >
>
> Done! Please review the patch submitted for #518 .
>

I noticed a possible minor issue while testing the patch (issue not caused
by the patch itself). I'm interested to hear your thoughts on the expected
behavior before I create a ticket.

With TracStandalone,

> config set components trac.wiki.* disabled

and a page refresh immediately shows that the wiki is disabled. However,
when the corresponding product command is run, tracd must be killed and
restarted for the change to take effect.

> product admin prod1 config set components trac.wiki.* disabled

I tested while disabling/enabling other components and had the same result.
Another possibly-related result of this is that the TracAdmin console must
be exited before the allowed commands for a disabled component are no
longer shown.

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message