bloodhound-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jared Duncan...@jdunk.com>
Subject Re: Bloodhound installation issue(s)?
Date Tue, 17 Sep 2013 06:05:58 GMT
>
> Also is there somewhere that clearly explains the n:m relationship between
> bloodhound installations, environments, products, wikis, and repositories?
>  e.g. "per bloodhound installation, there can be many environments, each
> environment can have many products, only one wiki per environment, shared
> by all products," etc,
>

Let me add "users" and "permissions" to this list too.  It appears the
scope of users/permissions is "site/project/environment-wide", i.e. if Joe
has "ticket_admin" permission, he does so for all products under the
project/environment/site.  But if there is another product which needs to
*not* be accessible to Joe, this product would need to be set up under a
different environment/site.  If Joe needed read-only access, a 2nd "joe"
user could be added to the 2nd environment/site, and this
separate-user-same-person joe could then be granted read-only privileges
for all products under that environment/site.  Does that sound about right?


On Mon, Sep 16, 2013 at 10:40 PM, Jared Duncan <j@jdunk.com> wrote:

> Ryan and Olemis, thank you very much!  Using the "product admin" command
> and specifying the product did the trick.  I would say it was highly
> non-obvious and I couldn't find any documentation nor anything googleable
> regarding how to finish one's setup.  Even just something at the end of the
> installation page (or anywhere) that says "btw the only way to modify your
> components, versions, priorities, ticket types, etc, is to use trac-admin,
> and with bloodhound you want/need to use the 'product admin' command, and
> this is what 'prefix' and 'sub-command' mean, and here is at least one
> example."  Would have saved me a lot of grief -- glad it has already been
> identified as confusing and hopefully a blurb like that is on the way; I
> think that would really improve the adoption.  Oh, and also "Add
> permissions to unlock a lot of hidden functionality in the UI" would be
> another great recommended "next step" for setup.
>
> I don't know how much of that is moot with 0.8, but I imagine a lot would
> still apply.
>
> Also is there somewhere that clearly explains the n:m relationship between
> bloodhound installations, environments, products, wikis, and repositories?
>  e.g. "per bloodhound installation, there can be many environments, each
> environment can have many products, only one wiki per environment, shared
> by all products," etc, and also at what level the UI operates exactly (eg
> "there is one UI per environment; multiple UIs can be set up for each
> bloodhound installation by running multiple tracd's and/or VirtualHost
> 's").
>
> I'll start a new thread for my other main issue to keep things clean here.
>
> Thanks again!
>
>
> On Mon, Sep 16, 2013 at 7:38 PM, Olemis Lang <olemis@gmail.com> wrote:
>
>> Hi Jared !
>>
>> On 9/16/13, Ryan Ollos <ryan.ollos@wandisco.com> wrote:
>> > On Mon, Sep 16, 2013 at 6:50 PM, Jared Duncan <j@jdunk.com> wrote:
>> >
>> >> Hello list.  Bloodhound looks fabulous and I'm very eager to use it,
>> but
>> >> I'm facing some frustrating show-stoppers during the setup phase.
>>  (I'll
>> >> keep it to just the main one in this email.)
>> >>
>>
>> Thanks for your interest in using Bloodhound .
>>
>> [...]
>> >>
>> >> Installed version 0.7 on Ubuntu and ran bloodhound_setup.py with
>> >> arguments
>> >> for sqlite, a project name, and an initial admin user.  Via tracd, the
>> >> Web
>> >> UI runs and through it, I can create wiki pages and tickets and
>> >> milestones.
>> >>
>> >> However, there seems to be a heavy disconnect between the data that
>> >> trac-admin sees and the data that the Web UI reads from / writes to.
>> >> Also,
>> >> what trac-admin sees seems to be missing quite a lot of the initial
>> data
>> >> it
>> >> should have.
>>
>> This is happening because of mapping Ā«globalĀ» URLs to resources in
>> default product . The different challenges and confusion this has
>> caused has been identified and the project have decided to get rid of
>> this redirection . These changes have been committed in /trunk and
>> should be ready in next release 0.8 (or whatever version comes next ;)
>> .
>>
>> There are a few implications though . We are working on those atm.
>>
>> >> For example, here is some output from trac-admin:
>> >>
>> [...]
>> >
>> > Milestones, components, severities, etc are associated with products.
>>
>> That is a fact ...
>>
>> > Try:
>> >
>> > trac-admin $tracenv product admin @ milestone list
>> >
>>
>> Two comments :
>>
>>   - if a custom default product prefix is specified at installation time
>>     (which I'd recommend) then replace @ with <your_prefix>
>>   - In general product admin <prefix> <sub-comand> followed by a
>>     command will apply a TracAdmin command upon product resources
>>   - In 0.7 under certain conditions you could use the global environment
>> as
>>     usual ...
>>     * ... and some resources may be still hosted by the global
>>       environment e.g. wiki , repositories
>>
>> [...]
>> >
>> > We might consider providing a hint to the user when they execute
>> > "trac-admin $tracenv milestone list".
>> >
>>
>> Default product redirections have been removed in /trunk . Why bother
>> with doing so ?
>> ;)
>>
>> --
>> Regards,
>>
>> Olemis - @olemislc
>>
>
>

Mime
View raw message