On 17/10/12 12:03, Ryan Ollos wrote:
On Tue, Oct 16, 2012 at 4:44 AM, Gary Martin <[email protected]>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
