Eirik Schwenke kirjoitti: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Jani Tiainen skrev 26-06-2008 19:03: > | Michael Stratmann kirjoitti: > |> On 26 Jun., 10:54, Jani Tiainen <[EMAIL PROTECTED]> wrote: > (...) > |> 4. 'Reject' is not final. Give the owner a chance to 'Reopen' (similar > |> to 'New'). At my last customer had a lot of upset test engineers, > |> because 'Reject' was not told them and often done in disagreement. > |> If owner agrees or after time limit, nobody opposes, 'Reject' becomes > |> 'Closed' as well. > > I see how this is useful, but isn't that how things work - resp to being able > to re-open? > > I certainly think this "hold a bit before closing" is a good idea, but > following the principle of keeping history, and not throwing away data, it > would seem a bit strange if bugs can't be reopened ? > > Forgive me if my assumptions are wrong -- I'm not currently using trac for > ticketing. > > Btw, is there a built in scheduler(aka cron) in trac ? It would certainly be > nice to have this feature as part of the system, if it isn't already (eg with > automatic escalation of old bugs, optional automatic transition to "won't fix" > for "dead" bugs, nagging devs etc). > > (...) > | You can add states, but you can't restrict them very well (?) to certain > | roles. > | > | This is something that we miss too - for example we would like to make > | tickets closable only by project managers after they have agreed with > | customer that ticket is done. > | > | It's my intention to expand current Trac user management to support > | roles and bring this kind of "role" thinking to Trac. But it's something > | that happens somewhere beyond 0.12... > > I see where this demand is coming from -- but is it really useful? I can maybe > see the need for this in a very public project (like demanding only authorized > users have change-rights to a wiki -- which in many ways goes against the very > principle of open/easy contribution -- but often is needed to avoid defacing > etc. Or at least often *perceived* as necessary).
Very private project that has internal (devs, project management etc.) and external users (end users, end user project managers etc.). Also it would enable features like (Now I'm talking about this usermodel thingy in general) "watch ticket" and "watch wikipage" and you get (e-mail) notifications about changes. Contrary to that CC-list Trac now have. > It would appear to me that in any kind of internal setting, restricting > changes > in ticket in the system wouldn't be all that useful -- simply tell the devs: > "Please don't do that". Tell that to end users too. In private, closed environment it's manageable. Also works very well in totally open. But try to mix these two... > In what kind of settings is this actually a real problem? When is it more > useful to have these kind of restrictions, than allowing a dev to mark > something as "ok" after a quick chat with a q&a person by the water cooler/on > im/etc ? Setting where you allow end users to enter tickets. I definetly don't want to give all power that devs have to change properties since it would only lead to maintenance hell: users tend to enter highest priority to all their bugs, change it to be released asap etc. Preferably I would do this in two different projects totally, but since Trac is missing solution to have multiple projects inside one environment it pretty much ruled out that possiblity. -- Jani Tiainen --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Trac Development" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/trac-dev?hl=en -~----------~----~----~----~------~----~------~--~---
