On Thu, May 30, 2013 at 10:21 PM, Olemis Lang <[email protected]> wrote:
> On 5/30/13, Ryan Ollos <[email protected]> wrote: > > On Thu, May 9, 2013 at 12:46 PM, Olemis Lang <[email protected]> wrote: > > > >> On 5/8/13, Gary Martin <[email protected]> wrote: > >> > On 08/05/13 18:06, Olemis Lang wrote: > >> >> On 5/8/13, Gary Martin <[email protected]> wrote: > >> >>> On 08/05/13 16:15, Olemis Lang wrote: > >> >>>> On 5/8/13, Gary Martin <[email protected]> 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. > > > > I'd have to confirm my hypothesis but maybe this is because of caching > . Components enabled / disabled state is cached in-memory . There's a > chance for it to get updated once config file is written because it's > reloaded from scratch afterwards (or based on file timestamps) . > Nevertheless , there's no such reloading mechanism for DB config > values . > > This is a good catch , if you please could create a new ticket then > I'll take a look and should be ready for next release . > > -- > Regards, > > Olemis. > Thanks, Olemis. Ticket opened is #539.
