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 <[email protected]> wrote:
On 2/20/13 5:21 PM, Olemis Lang wrote:
On 2/20/13, Andrej Golcov <[email protected]> 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
