On Wed, Oct 17, 2012 at 4:34 PM, Gary Martin <[email protected]>wrote:
> 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. > > > 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 moment). > >> 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<http://trac.edgewall.org/ticket/8778> >> (2) >> http://trac-hacks.org/wiki/**SimpleTicketPlugin<http://trac-hacks.org/wiki/SimpleTicketPlugin> >> (3) >> http://trac-hacks.org/wiki/**BlackMagicTicketTweaksPlugin<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 >
