Endre Bakka kirjoitti: >> there is: >> * http://trac-hacks.org/wiki/AccountManagerPlugin >> * user mgt api: http://trac.edgewall.org/ticket/2456 >> * nick as login: http://trac.edgewall.org/ticket/3737 > > Interesting, but these are mainly meant for the administrator. I was > thinking about preferences the user sets himself, e.g.: > always_notify_owner, always_notify_reporter and always_notify_updater > should be set on a user-basis (actually, I think this should be set on a > ticket basis as suggested in #6217, but it was the best example I could > think of). > > - Endre > > >> On Nov 11, 11:54 am, Endre Bakka <[EMAIL PROTECTED]> wrote: >>>> 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?
This could be that database entry that is identified by some unique key. There is already existing, though very rudimentary, user preferences table in Trac that is identified by simple (hash?) key. By coupling this key with login it would give lot of oppurtunities. What would be really useful in future: (Not sure does this exists anywhere written, but I just write it here) Checkbox on ticket/wiki that says "Notify me if something changes". Then you would get e-mail about changes. Simple but effective and there wouldn't be need for distinguish creator or some arbitary listener. It would remove need for that cc litter in tickets, also it would prevet removing someone elses e-mail from cc-list. Also it would be easier to change your interests in preferences page where you could easily remove yourself from items you're following and in the first place. This would also prevent e-mail address gathering. Now anyone who can access Trac tickets can pretty easily extract bunch of e-mail addresses just by going through tickets since there wouldn't be necessary to expose any listening e-mail addresses (at least for normal users who wouldn't see list of listeners at all). Just my 0.02€... -- 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 -~----------~----~----~----~------~----~------~--~---
