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
-~----------~----~----~----~------~----~------~--~---
