On 6/7/13, Branko Čibej <[email protected]> wrote:
> On 07.06.2013 21:54, Matevž Bradač wrote:
>>
>>> And another thing.. aren't we meant to have ticket numbers being used
>>> sequentially within each product? Would this break anything else?
>> The ticket id is an auto-incremented database key, so I don't think that
>> would work.
>
> I thought we agreed a while ago that there are two ticket identifiers:
> the ticket-id, which is the same as in trac and the primary key of the
> ticket in the database; and the product-prefixed id, which is scoped
> within the product prefix and serves as an alias.
>
Once upon a time this looked ok to me.
> The reason for doing is this way should be obvious -- a) you maintain
> immutability of existing ticket URLs after multiproduct upgrade,
Even if this might be seen as a logical consequence , now in practice
it's not .
1. In global context the DB cursor used to access
ticket table is scoped to product=''
2. AFAICS default hooks will redirect global /ticket/... requests
onto default product (failing if not properly configured) .
So, unless I am missing something, the current situation consists in a
single ticket ID sequence (due to ticket DB auto inc field) not fully
accessible even in global scope
> and b)
> when you import a new product (from, e.g., Jira; or, e.g., Subversion's
> issue tracker) you can keep the same product-prefixed IDs regardless of
> the ticket-id primary key gets assigned to the database record. This is
> a very important property of ticket IDs, IMNSHO.
>
considering the fact that now ticket table's key is it's ID then there
are two options
1. introduce another DB table to map product-specific
ticket seq number to global seq number .
* MP ticket module must be aware of this new table
* also afaics it has an impact on other parts of the system
including, but not limited to, milestones, authz permissions,
wiki syntax , attachments, resources, ...
2. upgrade ticket primary key to become (product, id)
* afaics this choice has an impact on ticket module
I'd argue that it'd be nice to stick to option (2) , if feasible .
--
Regards,
Olemis.
