On Wed, May 25, 2011 at 12:18 AM, Jeroen Vermeulen <j...@canonical.com> wrote: > 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.
I do agree that avoiding special cases is a good idea, and having actual 'Person' objects for these things avoids special cases to describe who took an action. I think having different service accounts for these things is sensible for a couple of reasons. One is separation of concerns: its much easier to have a tightly scoped role than to have one mega-powerful service account. If that account were to be compromised, messy stuff would happen. Managing more credentials is a tradeoff, of course. Secondly, many (all) of the examples so far are great examples of things we could run as external services. Its easier to identify problematic clients if they have different ids. In terms of where we might want to be: * Code should be able to assert that a particular service account exists and have it made just-in-time. * We shouldn't conflate name-lookup for these Persons with regular users: they should be exposed as Person (and so have a Person row) but they should also exist in a dedicated 'internal service account' namespace where their unique key cannot collide with the public name. This would let us rename them safely in the public eye: our code would lookup by the service name (which is what the existence assertion would take). * We should show them in a visually distinct way to educate folk about them. We're not far off there. Minimally: * adding a service_name field to Person, with a UNIQUE constraint. * Adding a trivial API collection to show all persons with service names. * And a login code check that prevents such accounts logging into OAuth or OpenID. would be enough to make it safe to write an existence assertion and thus avoid further headaches with deployment skew. How does that sound? -Rob _______________________________________________ Mailing list: https://launchpad.net/~launchpad-dev Post to : launchpad-dev@lists.launchpad.net Unsubscribe : https://launchpad.net/~launchpad-dev More help : https://help.launchpad.net/ListHelp
