launchpad-dev team mailing list archive

[Jeroen Vermeulen <jtv@xxxxxxxxxxxxx>]

On 2011-05-24 03:23, Robert Collins wrote:

> I think that we have two categories of actors:
>   - internal actors
>   - actors of clients of launchpad
>
> For the former we *might* want a single service account. *might*. I've
> yet to see a convincing argument for its utility. What we usally want
> IME is impersonation: The ability for a service to act 'on behalf of
> user Fred' when journalling actions etc.
The former is the only part I'm asking about: a celebrity that can own 
things, be the author of messages etc.  Not an actor in the strict sense 
of the word, although it may be seen as one from the user's point of view.
We've been creating these persons irregularly and ad-hoc, with the sheer 
inconvenience as the main moderating factor — plus nowadays the ban on 
new sample data, and possibly fine-grained rollouts requiring a new 
celebrity to be created on the production / staging / qastaging / 
dogfood databases.
As you say, impersonation is _usually_ what we want but I'm talking 
about the cases where it isn't: things that Fred reasonably sees 
Launchpad rather than himself as doing, or ones where the connection to 
Fred is tenuous, or cases where there is no Fred, or a role that confers 
privileges that Fred may not deserve.  That set is nonempty, and it may 
be worth having a catch-all to head off further growth.
Examples:
 * Janitor.
 * Various import and export acknowledgements.
 * The Q/A tagger.
 * Launchpad Registry as a placeholder for "un-owned."
 * Authorship of Launchpad-generated translation credits.

What I'm working on at the moment is a stream of UI-visible Messages 
that may contain free-form messages from users, but also error messages 
from Launchpad.  There are other solutions for that one, but they tend 
to go in uncomfortable directions like "Message.author is the person who 
entered the message, except when..."
So: should we have a single celebrity that we can fall back on to 
represent Launchpad as a user for such things?  If not, we can continue 
expanding the cast of gnomes that the user sees working inside 
Launchpad.  But I'd feel much better if we at least had a clear idea of 
when and how and why to create these gnomes.

Jeroen