incubator-bloodhound-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Gary Martin <gary.mar...@wandisco.com>
Subject Re: [Apache Bloodhound] #234: Quick Ticket: link to /newticket, description and priority
Date Wed, 17 Oct 2012 14:34:21 GMT
On 17/10/12 12:03, Ryan Ollos wrote:
> On Tue, Oct 16, 2012 at 4:44 AM, Gary Martin <gary.martin@wandisco.com>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.

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

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 be
> shown on the newticket form, or in the modify ticket section of the ticket
> page.
>
> (1) http://trac.edgewall.org/ticket/8778
> (2) http://trac-hacks.org/wiki/SimpleTicketPlugin
> (3) http://trac-hacks.org/wiki/BlackMagicTicketTweaksPlugin
>

Interesting.. these might be worth looking into further if this kind of 
behaviour is seen as appropriate.

Cheers,
     Gary

Mime
View raw message