It would probably be better to post this to the trac-dev mailing list,
where these kinds of issues are discussed more often.
Food for thought though, validate_ticket is a discussion between a single
user (possibly supplying incorrect parameters).
ticket_changed can be thought of in the same way, but may not originate
from a single request. I'm thinking of tickets which are deleted or closed
on polled intervals, also batch modifications. That or tickets which are
changed by functionality like what you are proposing (but on the same
server). I can see that the request might be useful... but I'm not really
sold that it isn't a security risk.
Can you use the author who made the last change, and then communicate those
changes to the same plugin installed on the other server? The end effect
being that the other plugin uses the ticket model on that server to do the
update with that author information. This way you aren't transmitting
session authentication etc but still capture who made the change.
You'd also have to pass the request information to save_changes in the
ticket model which actually calls all the ticket listeners:
{{{ http://trac.edgewall.org/browser/trunk/trac/ticket/model.py#L257
def save_changes(self, author=None, comment=None, when=None, db=None,
cnum='', replyto=None): # <--- NOTE: No req parameter here.
[... Do stuff in the db to save changes ...]
for listener in TicketSystem(self.env).change_listeners:
listener.ticket_changed(self, comment, author, old_values)
}}}
Which is originally called in the web_ui under _do_save in the TicketModule
class.
{{{ http://trac.edgewall.org/browser/trunk/trac/ticket/web_ui.py#L1297
def _do_save(self, req, ticket, action): #<-- NOTE : So here is your req
[...]
cnum = ticket.save_changes(get_reporter_id(req, 'author'),
req.args.get('comment'), when
=now,
replyto=req.args.get(
'replyto'))
[...]
}}}
I think there must have been a reason that they didn't pass the whole
request on at this point and decided to parse it's attributes instead.
-Nelson
On Fri, May 25, 2012 at 9:27 AM, Willmer, Alex (PTS)
<[email protected]>wrote:
> Hi all,****
>
> ** **
>
> TLDR: ITicketManipulator.validate_ticket() supplies a req parameter,
> ITicketChanged.ticket_changed() doesn’t. Is this an intentional design
> decision, or would patch that adds an optional req parameter be considered
> for inclusion with Trac?****
>
> ** **
>
> I’m currently finishing the remote ticket plugin I started long ago. The
> plugin will eventually allow a ticket to be linked to another ticket in
> another project – provided it’s run using the ticketlinks branch of Trac.*
> ***
>
> ** **
>
> In the plugin I am using ITicketChanged interface as a trigger to RPC
> update of the tickets in other projects. To authenticate to the other
> projects it’s very useful to have a req instance - which the
> ticket_created()/ticket_changed() methods don’t currently supply. For now
> I’m performing a horrid hack in ticket_validate() - saving a reference to
> req as an attribute on the Ticket instance.****
>
> ** **
>
> Is there a better way to achieve my goal: when a ticket changes locally,
> attempt to update remote linked ticket to match – reusing any
> authentication tokens that we included with the request. Otherwise, do you
> think extending ITicketChanged (to optionally provide req) would make a
> sensible evolution of Trac? Or is that a horrid architecture violation?***
> *
>
> ** **
>
> I’m thinking the signature could become ticket_changed(self, ticket,
> comment, author, old_values, req=None) or ticket_changed(self, req, ticket,
> comment, author, old_values) with an arity() check like
> post_process_request().****
>
> ** **
>
> The plugin code I’m currently using looks like:****
>
> ** **
>
> class RemoteLinksProvider(Component):****
>
> """Validate and save remote ticket links when a ticket is modified.***
> *
>
> """****
>
> implements(ITicketChangeListener,****
>
> # ITicketChangeListener methods****
>
> def ticket_created(self, ticket):****
>
> self.ticket_changed(ticket, '', ticket['reporter'], None)****
>
> ** **
>
> def ticket_changed(self, ticket, comment, author, old_values):****
>
> ….****
>
> # Push changes to remote sites****
>
> req = ticket._evil_remote_ticket_hack****
>
> self._update_remote_sites(ticket, req)****
>
> ** **
>
> # ITicketManipulator methods****
>
> def prepare_ticket(self, req, ticket, fields, actions): ****
>
> pass****
>
> ** **
>
> def validate_ticket(self, req, ticket):****
>
> ….****
>
> # Evil hack alert! Need a way to authenticate to any remote hosts,
> if****
>
> # there are changes to the remote ticket links. However once we
> reach****
>
> # ITicketChangeListener ticket_changed() Trac doesn't provide the*
> ***
>
> # request object****
>
> ticket._evil_remote_ticket_hack = req****
>
> ** **
>
> Regards, Alex****
>
> *-- *
>
> *Alex Willmer *| Developer*
> *2 Trinity Park, Birmingham, B37 7ES | United Kingdom
> M: +44 7557 752744****
>
> [email protected] | www.logica.com
> Logica UK Ltd, registered in UK (registered number 947968)
> Registered Office: 250 Brook Drive, Green Park, Reading RG2 6UA, United
> Kingdom****
>
> ** **
>
> Think green - keep it on the screen. This e-mail and any attachment is for
> authorised use by the intended recipient(s) only. It may contain
> proprietary material, confidential information and/or be subject to legal
> privilege. It should not be copied, disclosed to, retained or used by, any
> other party. If you are not an intended recipient then please promptly
> delete this e-mail and any attachment and all copies and inform the sender.
> Thank you.
>
> --
> You received this message because you are subscribed to the Google Groups
> "Trac Users" 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-users?hl=en.
>
--
You received this message because you are subscribed to the Google Groups "Trac
Users" 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-users?hl=en.
