incubator-bloodhound-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jure Zitnik <j...@digiverse.si>
Subject Re: [BEP-0003] Database upgrade to multi-product (Was: Re: [Apache Bloodhound] #406: Database upgrade to multiproduct)
Date Fri, 22 Feb 2013 10:41:12 GMT
On 2/22/13 3:03 AM, Branko ─îibej wrote:
> On 21.02.2013 18:05, Olemis Lang wrote:
>> On 2/21/13, Jure Zitnik <jure@digiverse.si> wrote:
>>> On 2/20/13 5:21 PM, Olemis Lang wrote:
>>>> On 2/20/13, Andrej Golcov <andrej@digiverse.si> wrote:
>> [...]
>>>>> My suggestion is to keep things simple here: if there is already
>>>>> product named "Default', let's assign global tickets to this product.
>>>>> There should be reason why this product was called "Default" :)
>>>>>
>>>> -1 ... IMO we the prefix for the global environment should be an empty
>>>> string (i.e. '') or NULL (/me slightly in favor of the former) . That
>>>> will allow us to reserve special behavior for that prefix value (if
>>>> needed) and will not clash with any other valid product prefix since
>>>> it's a required field in create product web form (... admin command ,
>>>> ...)
>>>>
>>> Just to clarify, the prefix of the 'global environment' is an empty
>>> string (''). This will, at the moment, only be used for permissions.
>>>
>> Yes , understood .
>> ;)
>>
>>> The 'default' prefix (or 'def') is used for a product to which all the
>>> tickets that don't have product assigned are migrated to (during the
>>> database upgrade process). The product itself is automatically added
>>> during the upgrade/migration process.
>>>
>> That's kind of what I was meaning in my reply .
>>
>>    1. Consider ticket without product before migration to be
>>        tickets filed against the global environment .
>>    2. Use gobal env just like any other product env with
>>        prefix = '' , not just permissions
>>    3. No need to create 'default' product while on upgrade
>>
>> PS: In the migration process we should also replicate (i.e. in DB) or
>> inherit product configs from a single file . I advocate for the later
>> .
> I have to say that for once I completely agree with Olemis. NULL table
> column, and empty UI prefix equals "it all looks exactly like it used to
> before the migration" and it also can't collide with any existing
> product names or prefixes.
>
> Furthermore, doing it this way, if a user installs Bloodhound but
> doesn't want to bother with product namespaces, everything will Just Work.
>
I agree with the 'Just Work' part, I don't agree with tickets in global 
scope.

My understanding was, based on the mailing list discussions, that we 
don't want tickets in global scope. That is why current implementation 
creates the 'default' product and migrates the tickets. I think that the 
'Just Work' part is more of the UI/UX issue. I think that each ticket 
should be linked to a product, it's up to the UI to make it easy for the 
user to use environments with only one product (default one). I find 
tickets in global scope confusing as it's not exactly clear what they 
relate to.

I would advocate global wikis for example, as it makes more sense.

Cheers,
Jure



Mime
View raw message