bloodhound-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Peter Koželj <>
Subject Re: [Apache Bloodhound] #234: Quick Ticket: link to /newticket, description and priority
Date Wed, 17 Oct 2012 16:00:56 GMT
On Wed, Oct 17, 2012 at 4:34 PM, Gary Martin <>wrote:

> On 17/10/12 12:03, Ryan Ollos wrote:
>> On Tue, Oct 16, 2012 at 4:44 AM, Gary Martin <>**
>> wrote:
>>  [...]
>>>> I think version needs to be there. For any ticket that is a bug, it is
>>>> important to know which version!
>>>> And for any project that does feature planning, version is important for
>>>> all ticket types.
>>>>  I would be happy with that. Associating a bug to a version, where they
>>> are
>>> defined, should be available.
>>>  +1 ... having a user report a bug without a version is almost always
>> undesirable, so at least we should put the Version field right in front of
>> them.
> It gets interesting where really you want to raise a bug against multiple
> versions but it is not the end of the world. The main thing is that there
> is a prompt for a primary version to raise against - further versions would
> probably be expected to be noted in the description and those dealing with
> the ticket could then determine whether further tickets are needed.
I was just thinking about the multiple versions per ticket (bug) support.
This needs to be formal and not just a in-comment or in-description text. I
have some ideas how we could go about this but it is off topic for this
ticket. I'll start a separate discussion on the subject at some point in
the fure (opening multiple unrelated tickets should be good enough at the

>>  Components should be good too and we appear to be missing product from
>>> the
>>> list.
>>>  Ideally this should be user configurable but we could also auto-hide any
>>>> fields for which there are no values defined (id a project does not use
>>>> components, don't show them).
>>>>  Perhaps, in the long run, we should make these things configurable
>>> based
>>> on permissions for a given project. That could make it local policy to
>>> say
>>> whether an anonymous user (for instance) is allowed to set specific
>>> aspects
>>> of tickets. This would probably have to extend into the newticket
>>> interface
>>> too.
>>>  I also like the idea of having TICKET_VIEW_<FIELD> and
>> permissions. One use case is, in the past, I've had the need to restrict
>> who can assign the milestone, and I suspect this would be common in
>> organization for which only the configuration control board or project
>> manager should be able to set the ticket milestone.
> Yes, this is the case I have in mind in particular. It would be silly to
> expect an anonymous user who is allowed to raise a ticket to also be able
> to set when it happens.
>  Similarly, we have a
>> use-case on trac-hacks for revoking some fields that are abused by
>> anonymous, such as Priority or Severity, and ideally these might only be
>> set by the product owner.
> Indeed, although I think these cases also suggest that we should also be
> able to set permissions that only allow initial setting of a field. In the
> case of Priority/Severity you might want to use one to indicate a
> customer's preference and the other to indicate internal priorities of
> course.
> Talking of which, Severity should probably be in the list of fields to put
> in the quick ticket dialog when a choice of severity levels is available.
>  Following the thought you started of extending this to the newticket
>> interface ... the permissions would also allow for simplifying the ticket
>> entry form, in ways that the SimpleTicketPlugin (2) and
>> BlackMagicTicketTweaksPlugin (3) have tried to do. If the user only has
>> only TICKET_VIEW_<FIELD> permission, the <FIELD> presumably wouldn't
>> shown on the newticket form, or in the modify ticket section of the ticket
>> page.
>> (1)**ticket/8778<>
>> (2)**SimpleTicketPlugin<>
>> (3)**BlackMagicTicketTweaksPlugin<>
> Interesting.. these might be worth looking into further if this kind of
> behaviour is seen as appropriate.
> Cheers,
>     Gary

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