bloodhound-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ryan Ollos <>
Subject Re: [Apache Bloodhound] #234: Quick Ticket: link to /newticket, description and priority
Date Wed, 17 Oct 2012 11:03:54 GMT
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

> 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 TICKET_EDIT_<FIELD>
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. 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.

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 be
shown on the newticket form, or in the modify ticket section of the ticket


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