> The notifications rework is still scheduled for 0.12 as far as I know, > and will probably be a pretty significant rewrite (you aren't the only > one frustrated by the current notifications framework). Really anything > less than that will just compound the problem by ending up with an even > more complex version of the existing system.
Well, I partly agree. But at the same time, if the change doesn't contain any cross-dependencies with other modules, then I see no reason not to add it now. The module scheduled for a rewrite will become more complex, yes, but it will only contain the functionality you want in the new module anyway. Also, it serves as a reminder to what needs to be implemented, and in many cases the code, or at least part of it, can be reused as well. Now, the main problem in my suggested solution is that I add a user preference stored as a session variable that the ticket module needs access to. This is a coupling that might be unwanted and is why I posted a question in the first place. An alternative is of course to add a global setting to trac.ini (e.g. notify_on_own_changes) in which case only 4 lines of code is needed in get_recpients (well, you also need some tests). But as I wanted to avoid using a global settings, I figured I would try a user preference instead. Has there been given any thought to how user preferences should be stored? - Endre --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
