> Interesting idea, and way better than what we have today for sure. I have
> given the notifcation system some thought as well ("various checkboxes
> turning on and off certain states" might be me), so I wanted to chip in
> with my two cents.
>The problem with per-ticket rules and lots of check boxes is no one is gonna be happy. There's no less then two tickets on t.e.o I saw which referenced such a preference, and where one person wants a lot of options, another wants only a few. I'm not even sure what I want! *laugh* Which is part of the reason why I was going for a pluggable architecture in and of itself. My original thought was as follows (short version): > (snip per-ticket notifications and default choices) > I love the filters you propose - that's way more flexible and powerful > than what I had envisioned, but I also miss the possibility of adjusting > the notification settings for each and every ticket. Of course, adding > notification for a single ticket is just a matter of creating a > subscription with "ticketid=433", but if you want to change the filter for > a ticket that already is caught it starts getting cumbersome. > > Have you given this aspect any thought? > I have actually, and have such a thing planned.. but not for the core Announcer plug-in (so far that's the name I've come up with). The basic system will have the user-editable subscription system letting people set rules; "mine", "all, with priority > 3" or "others, with milestone matches Release-*" and such. Everytime a ticket is changed, the TicketSubscription component (an implementation of IAnnouncerSubscription) would scan the list of rules it has cached and see if that ticket matches any of them. The rules are stored for the user, not the ticket-- but you're right. If someone wants to make a per ticket rule, they could easily make "all, with id = 433". But that's beyond cumbersome, you're right. :) Instead, I have in mind a WatchedTicketSubscription plug-in that can be added. It's separate from the core announcement architecture, and would in theory add a 'Watch This' button to the ticket UI-- however one goes about doing that, I don't know yet :) It might have various options you can select (comment added, status changed, etc). How it stores these choices and determines that you want to watch Ticket #4 has nothing to do with how the filters above work; the system itself doesn't require subscriptions to be stored or processed in any particular way. The rules above were just one implementation of determining subscriptions, a general purpose subscription system; a specific desire could just be a plug-in on that core... an IAnnouncementSubscription implementation could decide that you have a subscription based on the phase of the moon if it wants :) The idea is one plug-in component implements the rule-based filter system for general preferences; one mimics current behavior to allow the system to completely replace the core notifications if desired while letting someone turn off certain features and refine with the rules; one which adds a 'watched' tag (with varying levels of specifity) to wiki pages and tickets. One does something I hadn't thought of. All look the same to the AnnouncementSystem master; all just report back subscriptions to an event. > > > idea floating in my head for /how/ ends up not working at all. Ahem. Is > > such > > a system desirable in core-Trac? If not I'll just keep it when I'm done > > :) > > As Alec suggested, a plug-in is the way to go. It will be available as > soon as it is finished (don't have to wait x months for the 0.12 release), > and you don't have to worry whether it will be accepted into the core or > not. You might discover that you need some new extension points, but these > should be fairly easy to get into the core. > Yeah, Plug-in it'll be. If I end up doing this, I expect it to be done on weeks if not a month or so-- it being a requirement to make the system work the way my company needs it to is motivational. My only real concern is it works for us; beyond that I'm pleased as punch if it ends up being useful for others. I'm still going through the core code and peering, and through the various notification tickets on t.e.o to see if anyone has thought of something I hadn't considered. (Now to see if the Boss will give me comp-days for work-related weekend work; making trac not spam him if he's not interested in something is surely day-job-work! :)) Thanks for the feedback/ideas. --Stephen --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
