I think the workflow plus a ticket filter (to prevent unmoderated "pending" tickets from being returned in a query) might work for anonymously reported tickets; however, I don't see how to use it for moderating ticket comments -- unless an anonymous comment moves the whole ticket back to the pending state (not very desirable).
On Sun, 2008-08-31 at 17:32 -0700, [EMAIL PROTECTED] wrote: > would the new workflow be a solution for that too? > > On Aug 28, 5:11 am, John Siirola <[EMAIL PROTECTED]> wrote: > > Folks, > > > > I have been using Trac on some internal projects for coming up on a year > > now, and was just presented with a new project that will require a new > > Trac plugin. I am new to both Python and Trac internals, so I would > > greatly appreciate any design guidance anyone might offer before I start > > blindly wandering in the dark. > > > > The situation: There is an open source project that would like to > > switch to Trac. We would like to support anonymous ticket creates & > > appends. The catch is the hosting provider is paranoid about ticket > > butchers and content accountability. The result is that we (by rule) > > can not allow anonymous users to directly edit any publicly-viewable web > > content. > > > > The idea: create a TicketModerator plugin that will take an incoming > > ticket (new or comment) generated by an anonymous user and put it into a > > "holding pen". It will then notify (e-mail) a dev, and the dev can > > click a link to either accept or reject the submission. > > > > I figure there are at least two possible ways to implement this: > > > > 1) route all anonymous contributions to a custom ticket state, and then > > write a ticket filter that will always hide those tickets from the web > > interface (i.e. queries, reports, browsing, etc). There are a couple > > problems, though... The hidden tickets / comments will occupy a space in > > the database: they will consume a ticket number or comment number that > > will show up as a hole until the record is moderated (or forever if it > > is rejected). Plus, while I could store new tickets with a custom > > state, what can I do with comments (maybe a sacrificial ticket to hold > > all pending comments???)? > > > > 2) Create new "pending" tables in the database that mirror the ticket, > > ticket_change, and ticket_custom schema. Then attach to something > > (ITicketManipulator or ITicketChangeListener?) to redirect incoming > > anonymous submissions to the pending tables. Separate code (attached to > > an IRequestHandler?) can handle the moderator's decision and either > > purge the record from the pen or move it into the real tables. For > > this, what is the process to make sure that the pending tables match the > > corresponding main table schemas? Can I really redirect the ticket > > storage location through the existing extension points? > > > > For the record, I have already gone over wiki/TracDev/PluginDevelopment, > > ComponentArchitecture (several times), and am starting to dig (randomly) > > through projects on trac-hacks. > > > > Thoughts and suggestions are greatly appreciated... > > > > Thanks, > > john > > --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
