RealmUser Model
  • RealmUser maps (realm, user) tuples to roles

  • Timestamp of creation of RealmUser stored, too.

  • Once authenticated, all RealmUser records retrieved for user, not just request's realm

  • At least one RealmUser record exists for each realm in

    RealmOwner, including users

  • RealmUser provides methods for standard queries (

    is_sole_admin)

Notes:

RealmUser is what joins a user to a security realm. The record gives the user a non-default role (not USER) in the realm. The time the user is joined to the realm is recorded in the table, and is useful for auditing and display purposes.

A user is also a realm. This enables user-oriented tasks (change password, update email, etc.) to be controlled in the same way as club-oriented tasks. This simplifies the security software and auditing. The user is the ADMINISTATOR of their realm. However, nothing in bOP prevents multiple ADMINISTATORs for a user's realm.

Once a user is authenticated, all RealmUser records are retrieved from the database for that user. This will get the (user, user) record, but other realms (clubs, general) are retrieved, too. When a link to a task is rendered, these values are used to determine if the link should be rendered or not ( task_ok).

There is at least one RealmUser record for each realm. This assumption is not widely used, but is important to ensure system integrity. For example, AdmSubstituteUserForm allows you to login as a club realm, which literally is impossible (a club is not a user). However, AdmSubstituteUserForm translates this to mean that the super user wants to be "any admin" in the club. Similarly, there is always a realm for any user, because all users own their own realm. This allows tasks like MY_CLUB_SITE to do something useful in all cases.

Bivio::Biz::Model::RealmUser provides several methods ( get_any_online_admin, is_sole_admin, is_auth_user, etc.) for quering the RealmUser table. These queries are cached on the request for performance.