bloodhound-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Peter Koželj <>
Subject Re: ticket associated with multiple versions (Was: Re: [Apache Bloodhound] #234: Quick Ticket: link to /newticket, description and priority)
Date Wed, 24 Oct 2012 09:36:06 GMT
On Fri, Oct 19, 2012 at 3:16 PM, Gary Martin <>wrote:

> On 19/10/12 12:11, Joachim Dreimann wrote:
>> On 18 Oct 2012, at 21:35, Gary Martin <> wrote:
>>  I had considered that but you would probably have to list out tasks
>>> within a ticket to cover per task workflow, wouldn't you?
>> I don't believe there should be a per task workflow. It should be a
>> ticket if it's big enough to need a workflow.
> I agree with that entirely. In addition I think it is generally better to
> be able to state that the work associated with a particular version is
> complete with the closure of a ticket having gone through the workflow that
> the project specifies.
> I think the idea of ticket substructure can probably work well but I am
> wary of using it for this purpose which may encourage users to shortcut
> local policy.
>>  This is why I was thinking of making use of structure around tickets for
>>> relationships that we are going to support anyway.
>>> Also, are we expecting that users might sometimes create tickets
>>> separately that should be joined by a multi version relationship? Would you
>>> pull them into a single ticket and mark the others as invalid?
>> That should be entirely up to the user.
> .. or local normal procedures, and I think we may want to help them with
> either choice.
>>  Can we envisage a way of having a ticket like interface to summarise a
>>> set of related tickets?
>> We have a few of these already: Products, Versions, Milestones. They are
>> like tickets in some ways, but their main purpose is to group tickets. We
>> could introduce kilometre-stones for a smaller measure⸮
>> - Joe
> If I were just talking about displaying a list of tickets, that would be
> easy - we will eventually be able to provide a way to construct a query
> which would show these specific relationships in a dashboard like focused
> view, but this is not really what I am talking about.
> Essentially tickets with ticket relations specified might be considered to
> have common conversations, particularly in a master ticket which, it might
> be argued, is worth displaying on subtickets of a given relation type. You
> could also argue that it might be worth allowing the master ticket of a
> relation to be expandable to show the subticket data in some way.
> The alternative I was suggesting before was more about allowing tickets to
> remain simpler whilst being able to get a view of the conversation and
> progress.
> Before doing that I would suggest that as a minimum we probably need
> ticket queries on the relations to be provided automatically in the ticket,
> along with the related ticket events to be shown in the activity feed.
> Cheers,
>     Gary

We should split this discussion into two steps. We should form some kind of
requirements first and only then discuss the implementation (multi version
per ticket vs. ticket per version).

I tried to sleep this over and than I questioned some of the colleges how
would they use such a thing and than I tried to sleep it over again :)

So this are my revisited guidelines that should drive multiversion
a) Adding the multiversion support should not complicate things for cases
where there is only a single or no version at all.
b) The basic multiversion functionality should be as streamlined as
possible and should deviate from the single version case as little as
possible while still adding some value. Any part of the multiversion
feature that would hurt usability (editing, searching, reports,
notifications...) needs to be optional to the user and left for the user's
project policy do dictate wether or how it should be used or not.


1. Affects version field [MUST]

User should be able to specify multiple versions to which the ticket
applies to. That is, a versions in which the bug appears in and not the
versions in which it will be fixed.

For non-bug tickets this field has no meaning and it should not be
available to the user. For all logic the value of the field should be
derived directly from fix versions.

Search can be done by "affects" field or by "version" field where "version"
is union of "affects" and "fix" fields.

This is essential functionality and it does not hurt the usability.

2. Fix version field [MUST]

User decides in which versions the ticket should be resolved.
This needs to be as simple as checking multiple versions in multiselect

3. Ticket data, workflow and search [MUST]

All data (description, comments, attachements, standar and custom fields,
status and resolution) are by default NOT version specific. It menas that
they apply to all specified versions and there is no version specific

Search can be done by "affects" and "fix" field like it does now over
version field. Search by "version" field should be changed to act like a
union of "affects" and "fix" fields.

4. Version specific data and workflow [NICE TO HAVE]

This should only be available when user requests it specifically (by
following special recipe for creating version specific tickets). UI and
search support for this can be very limited as cases that require version
specific data and workflow are normally very rare and are usually taken
care off by creating multiple unrelated tickets anyway.

5. Version specific resolution and verification [NICE TO HAVE]

If user so chooses he should be able to track version specific resolutions
and verifications. This should only be available if users marks the ticket
as such and must not interfere with usability when not selected. This does
not change the ticket workflow, it only gives the ability to enter version
specific resolution and verification.

As the ticket workflow and versions are not directly tied to the per
version resolutions, search functions as is. The usefulness of version
specific resolutions would benefit from search extensions that allows
versions search narrowing by specifying that one is only interested in
opened/resolved/verified versions.

Additionally a strict mode can be offered that would not allow for ticket
to be closed until all versions are resolved beforehand.


Now which of these do we want to implement and how is another metter
Point 1 needs to be solved in-ticket. I would also take that approach for
everything else except number 4 which has ticket relations written all over
it, but would not provide any special support on top of relations at the


  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message