Part of lp.registry.model
|Class||AlreadyConvertedException||Raised when an attempt to claim a team that has been claimed.|
|Class||ValidPersonCache||Flags if a Person is active and usable in Launchpad.|
|Function||validate_person_visibility||Validate changes in visibility.|
|Function||get_person_visibility_terms||Generate the query needed for person privacy filtering.|
|Class||PersonSettings||The relatively rarely used settings for person (not a team).|
|Function||readonly_settings||Make an object that disallows writes to values on the interface.|
|Class||PersonSet||The set of persons.|
|Class||SSHKeySet||No class docstring; 1/5 methods documented|
|Class||WikiNameSet||No class docstring; 3/3 methods documented|
|Class||JabberIDSet||No class docstring; 3/3 methods documented|
|Class||NicknameGenerationError||I get raised when something went wrong generating a nickname.|
|Function||generate_nick||Generate a LaunchPad nick from the email address provided.|
|Function||get_recipients||Return a set of people who receive email for this Person (person/team).|
|Function||_is_nick_registered||Answer the question: is this nick registered?|
|Function||_get_recipients_for_team||Given a team without a preferred email, return recipients.|
Prevent teams with links to other objects from transitioning, ignoring known-OK links.
person_sort_keyin the database.
When you write, the message is raised in a NotImplementedError.
See lp.app.validators.name for the definition of a valid nick.
It is technically possible for this function to raise a NicknameGenerationError, but this will only occur if an operator has majorly screwed up the name blacklist.
If there is a current browser request, we cache the looked up Person in the request's annotations so that we don't have to hit the DB once again when further adaptation is needed. We know this cache may cross transaction boundaries, but this should not be a problem as the Person -> Account link can't be changed.
This cache is necessary because our security adapters may need to adapt the Account representing the logged in user into an IPerson multiple times.
If <person> has a preferred email, the set will contain only that person. If <person> doesn't have a preferred email but is a team, the set will contain the preferred email address of each member of <person>, including indirect members, that has an active account and an preferred (active) address.
Finally, if <person> doesn't have a preferred email and is not a team, the set will be empty.