there is no way to store interesting data on the participation scripts set up

Moving to foundations, as digging has shown its systemic.

At the heart of it, this bug is:
 - exec_zcml_for_scripts should not call setupInteractionByEmail(ANONYMOUS)
 - scripts should login as a restricted access celebrity sufficient to determine what requests they need to service.
 - they should then impersonate the appropriate users as they process things (e.g. by logging out and logging in as that user).
 - errorlog.ScriptRequest might be a reasonable base to start from, but there is some hair.

Overall, I think that's a sound plan.

You might not need celebrities (i.e. database Person records known to Launchpad) for logging in that way. You might be able to use something more Zope-ish. I don't really know how this would work.

For some scripts, logging in and out as a particular user might not be appropriate. e.g. The branch scanner needs access to things that the branch owner does not have access to. Note that the XML-RPC service for codehosting is a functioning example of this "log in as requesting user" pattern.

On Tue, Aug 24, 2010 at 8:19 PM, Jonathan Lange <email address hidden> wrote:
> Overall, I think that's a sound plan.

Thanks for looking at it.

> For some scripts, logging in and out as a particular user might not be
> appropriate. e.g. The branch scanner needs access to things that the
> branch owner does not have access to.

it does ?

> Note that the XML-RPC service for
> codehosting is a functioning example of this "log in as requesting user"
> pattern.

Awesome.

-Rob

I think the bug summary is a bit strong; scripts set up perfectly _valid_ participations, but they are very boring ones. As discussed on the mailing list, I think we want to set up a participation that's more interesting (in particular, that supports annotations) but not go as far as having a participation that's implements IRequest.

The other things you mention seem to imply not using the PermissiveSecurityPolicy in scripts, which irrespective of being a good idea or not is definitely something different.

FWIW, when I said "as discussed on the mailing list", I'm talking about this thread: http://<email address hidden>/msg04389.html

Fixed in stable r14143 <http://bazaar.launchpad.net/~launchpad-pqm/launchpad/stable/revision/14143>.

So well, I landed something that allows a more principled way of storing data specific to an interaction. It doesn't address this bug precisely but I think it probably addresses the need. I believe this bug was created around the time the timeline code was being written and maybe this solution isn't totally appropriate for that -- as there will be some db queries before the interaction is set up. But I think that's probably surmountable.

What do people think? Should this bug be closed now?

I think its solidly possibly maybe closable. The acid test would be getting timelines to be automatically cleared and set when new work is started by scripts such as checkwatches.