-----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). 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". 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 ? Best regards, - -- ~ .---. Eirik Schwenke <[EMAIL PROTECTED]> ( NSD ) Harald Hårfagresgate 29 Rom 150 ~ '---' N-5007 Bergen tlf: (555) 889 13 ~ GPG-key at pgp.mit.edu Id 0x8AA3392C -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFIY9bUxUW7FIqjOSwRAlRoAJ49/qewkx20BmBUIwWF+a7bq2F5+wCeJEAD NXmzOiiOhCBGGCT0d8+dOyU= =0Jjv -----END PGP SIGNATURE----- --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
