On 14/11/12 08:38, Olemis Lang wrote:
On 11/13/12, Jure Zitnik <[email protected]> wrote:
On 11/7/12 9:58 PM, Gary Martin wrote:
On 7 November 2012 09:29, Branko Čibej <[email protected]> wrote:
On 07.11.2012 08:42, Jure Zitnik wrote:
[...]
I did a bit of code digging to get an idea how the product ticket
namespace could be implemented and I came up with a problem described
below ...
In my opinion the most obvious way to keep the product ticket namespace
would be to introduce a new database table that would link the product
to the ticket by adding additional info,
If you need a new product-specific ticket number sequence (which I
don't think is really needed , at least for the moment) maybe that's
ok *IF* other mechanism like custom ticket fields is not enough.
such as ticket sequence in that
namespace.
btw , what's the decision on having consecutive ticket sequence
per-product ? Is it a design goal ? That will only make things harder
at the beginning while we try to sort out more important puzzles . Can
we make it clear whether consecutive ticket sequence per-product will
be included or not ?
fwiw ... I'm -1 about adding it soon ... maybe later
At the moment I am of the opinion that it is something we need to sort
out relatively quickly so that fewer people feel any pain of a transition.
A single ticket number range in a system is the easy choice but leaves
us with a number of problems to consider when we look to import tickets.
For example, if an admin user wants to combine two existing trac
environments then the #ticketnumber links in comments and wiki pages
will fail. OK, so let's say that we could consider carefully adjusting
those ticket numbers to point to the new ticket numbers.. would we also
be looking at updating all the version control commit messages that
refer to tickets? This seems a bit much.
If instead we have continuous ticket numbering within a product, the
problem described above is potentially eased as we could consider
references to tickets from within a product to be referring to tickets
within the product. So within the bh product, #1234 will always refer to
a bh product ticket. This should work well for references *to* tickets
that used to be in the product as we can maintain old ticket links in
such a way that they redirect to the new ticket reference. References
*from* a moved ticket are a little more problematic - I tentatively
suggest that these would have to be detected and adjusted to specify the
old prefix at move time.
It would seem that version control will also have to be considered to be
linked to a specific product in order to make existing links work for
legacy ticket numbers.
As for the transition from a bloodhound with non-consecutive ticket
numbers within a product to this system, I suppose we might have to
allow for holes in the ticket ranges. Of course, this supposes that it
is something that people are already using.
By the way, something else that might be up for debate is the forms that
we want to allow prefixes to be specified. Reusing InterTrac links would
a natural fit as this would support bringing two environments together
that used to be linked with such links. For tickets, that would give us
links like:
* prefix:ticket:1234
* prefix:#1234
* #prefix1234
and I believe that these are case-insensitive. I think it may also be
worth considering adding the JIRA style BH-1234 at some point as well.
But as we want to perform the database inserts prior to sending out
email notifications (let's say we want to include newly generated URLs
from the product ticket namespace in the notification emails) we can't
really simply call the original/trac methods. So, to accomplish this
(single transaction for both inserts, product ticket namespace URLs in
notifications), we would need to literally copy parts of the trac code
to the overriden methods and add/modify the code to handle product
ticket namespace and notifications ...
An alternative might be to store details of the ticket sequences within
a product namespace on the ticket itself. This should allow us to make
use of Trac's standard update mechanisms and so keep these changes in a
single transaction.
The solution for adjustment of product resource URLs should happen
transparently . That's what «product environments» [1]_ are for . I'll
explain how they'd work soon once I continue writing BEP 3 . Feel free
to drop some ideas in there too ;)
[...]
Patching trac would
possibly solve this but if we want to keep the plugin functionality
separate from trac that's really not the proper way of doing things.
Please let's try to modify (copy , duplicate ...) code rarely , and
only if there's a very good reason to do so . Changing things in there
may break many other parts of the system and external plugins .
Using the trac code copy in overridden methods is also suboptimal. I
noticed though that the bloodhound theme (quick ticket create) sort of
uses this second approach.
Kind of ... but create_ticket has been copied from XmlRpcPlugin , so
it's a well-known , reliable (and tested ;) implementation .
I'm bringing this up partly because I have a strong suspicion that we'll
come across the same issues if/when we start thinking of implementing
per product wiki, components, milestones, versions, etc.
Yes . So the solution should not be to start patching Trac all over
and (it does not stop there) merging subsequent changes with time .
.. [1] Some ideas on Multiproduct architecture
(https://issues.apache.org/bloodhound/attachment/wiki/Proposals/BEP-0003/Multiproduct.png)
Cheers,
Gary
