Red Queen Review Engine User Manual

MEMBER RECORDS

Adjust Text:  a a a a
« Table of Contents   |   Obtain Red Queen »


MEMBER RECORDS

In general, Members will take care of themselves. Red Queen allows a site user to register as a Red Queen Member who identifies themselves each time they interact with a Red Queen form by supplying a username and password. When they register, a record is created in the Member table. In addition, a record is also created in the Red Queen User table. Why are there two member tables? The reason is that the Member table is used to hold information about a Member that is application-independent, like the name and email address of the user, while the User table contains information about user preferences--in this case for Red Queen. If you couple Red Queen to an external member database, such as vBulletin, Member authentication is performed by querying your external member table, but Member information is still read from the Red Queen tables. In this case the Member will have the option of keeping certain Member fields in synch with the corresponding external member fields.

Once a Member has been entered into the Member table (usually via registration), and they have been allocated a Member ID of, say, 7, then you can navigate to the Member profile page via the browsable Team Pages (if the Member has not joined any specific Team you can always look them up alphabetically), or you can enter the URL to the Member profile page directly into your browser, like so:

http://www.mydomain.com/cgi-bin/path/to/...
	/redqueen/do/redqueen.cgi?module=profile_member&member_id=7

Creating a Member

For the most part you will have NO need to create Member records, as Members create their own records when they sign up. On occasion, however, the need may arise to create or modify a Member record directly. Before proceeding, however, make a mental note that this discussion applies ONLY to the case where you are using Red Queen Member Management for member authentication. You cannot add new members if Red Queen is coupled to an external application, like VBulletin, for the member authentication. You will simply get an error message if you attempt to create new members this way. Instead, go through the member creation process of the other application (after which time an equivalent Red Queen member record will be created the first time the member logs into Red Queen).

The recommended way of adding a new Red Queen Member record is to go through the Member Registration process. The registration link is offered any time a user attempts to perform an action which requires authentication and they are not already logged in. There is also a link in the navigation bar for the public pages. That said, as the Administrator, you can create a new Member record, or edit an existing one, either by way of the Teams control panel--which is to say, the Member Browser--or the Database control panel--where you pull up the Member table in the Database menu. For completeness we'll cover the latter case, where the interface is slighly more complex. Again, the easiest way to add a Member is to use the registration form. Thus, if you go to the Database control panel and select the "Add" option from the Database menu, in addition to selecting the Member table, the right frame will load the following form elements (example input values have been added for clarity, and are explained below):

Member ID

A value will be assigned

Username

Password

Email

Nickname

Real Name

Homepage

Avatar

Image

Brief Bio

Biography

Location

Occupation

Keywords

Is Validated

Of particular note here is the password field. Passwords are MD5 encrypted to 32 characters. This means that the stored value for the password will look something like 68325d85dac29f47b4df5908d99f5cde once the record is created. The next time you attempt to edit the record you will see the MD5 value and not the original plain-text password. MD5 is a one-way hash, so if the password is forgotten by the member they cannot retrieve it, and a new one must be assigned.

Note: When you click on the submit button to create the Member record, you will at the same time create a corresponding record in the User table, provided your Member input fields are accepted. The difference between the Member and User tables is that the Member table contains personal information about the user, such as username, password, email address, etc, while the User table contains the application specific fields, like the email notification toggle and the review solicitation toggle, among others. The records in the two tables for a given user share the same member ID value.

Editable Member Fields

The following Member fields appear both on the Add Member and Modify Member pages, but the Password and Is Validated fields appear here ONLY because we are dealing with an Administrator Member record creation (ordinarily these fields are handled behind the scenes via the code that runs the Member Profile page, which allows Members to update their record themselves). Note that certain fields may be read directly from an external member table and then copied to the Member table each time a login occurs, so that the Red Queen and external tables remain in synch. Such fields are termed autosynch fields, and those which may be so are indicated below (exactly which are depend on the external application):

Member ID
Each Member record is uniquely identified by the Member ID (the actual column name is Member.id), a positive integer that represents the PRIMARY KEY for the table. This value is automatically created each time a new Member record is added to the table and is one greater than the Member ID value of the previous record to be inserted. In other words, the Member.id column is an AUTO INCREMENT field.

Username
This is the Login ID a Member will use when required to Login. This is field case insensitive unless coupled to an external authentication program which treats the Username in a case sensitive way (almost never the case). Red Queen requires registering Members to supply usernames between 3 and 12 characters in length. You should follow that rule too. The column is Member.username. This is an autosynch field.

Password
When a Member registers or changes their password via their Member Profile page, the password field is encrypted with MD5, unless an external authentication program is being used, in which case the treatment of the stored password depends entirely on the authentication program in question. Thus, if the stored passwords are encrypted you'll have to figure out the relevant string to go into this slot (this is why using the registration page to create a Member is easier--there you just supply the plaintext password). The column is Member.passwd. This is an autosynch field.

Email
Email address of the Member. The column is Member.email. This is an autosynch field.

Nickname
This is the name by which the Member choses to be known on public pages. The column is Member.known_as. This is NOT an autosynch field.

Real Name
This is the Member's real name, if supplied. The column is Member.name. This is may be an autosynch field.

Homepage
This is the Member's web address, if supplied. The column is Member.url. This is may be an autosynch field.

Avatar
The Avatar field is optional and is based on an INT (integer) column which acts as a foreign key to the Upload table. To add an avatar for the Member record click on the button marked "Manage Upload" and a dialog box will appear requesting information about the file to be uploaded. Once you have uploaded the image, a MIME icon and the name of the image file will appear on the Member record form itself, verifying that the image file is available before you even submit the Member record to the database. The column is Member.avatar_image.

Image
The Image field is optional and, like the Avatar, is based on an INT (integer) column which acts as a foreign key to the Upload table. The main difference here is that if you have enabled automatic image thumbnailing, a thumbnail of the uploaded image will also be stored along with the unscaled image and used where appropriate elsewhere in the program--such as on the Member detail page, or the Member Profile page. The column is Member.member_image.

Brief Bio
A Brief Bio field provides the short version of the Member's full Biography field, and is displayed, for instance, on a Team listing of Members when no other alternative Member bio is available (the Member can in fact supply a separate short bio for every Team they join, if they wish). The column is Member.brief_bio. This may be an autosynch field.

Biography
This is the full Biography for the Member, and appears only on the Member Profile page. The column is Member.full_bio. This may be an autosynch field.

Location
This optional field represents the Location of the Member. The column is Member.location. This may be an autosynch field.

Occupation
This optional field represents the Occupation of the Member. The column is Member.occupation. This may be an autosynch field.

Keywords
The Keywords field (column Member.keywords) is an optional string of comma-delimited words or phrases that will be used to populate metadata tags in the static version of Member detail pages. Their purpose is thus to help spiders correctly index your web pages. This is a VARCHAR(255) column, meaning that the length of the field is limited to 255 characters.

Is Validated
This ENUM column toggles between "Yes" and "No" and is used to activate or deactivate Members. If Member email addresses are validated, this field is set to "Yes" when the Member clicks on the link sent to them in their registration email. The column is Member.is_validated.

Editable Non-Member Fields

In addition to the Member fields shown above, there may be other non-Member fields which appear on the Add Member and Modify Member pages. Team Editors and the Administrator are able to modify the Teams associated with a Member, so one extra form element will be present to handle this. This form element will look something like the following (the form element is functional so you can play with it):

Teams

 

Team Pool

Note: You will discover if you try to remove all Teams from a Member record that you cannot do it. At least one Team will remain. This behavior may or may not change in the future. On the other hand, if a Member attempts to remove himself/herself from a given Team via the public interface, they will have no problem doing so.

Note also that these forms are only present when editing records via the Database control panel. If you are using the Team Browser to add and edit records, look for the Copy link that appears next to each member in a team listing. You can copy the member to another team using point and click operations. But you can only do this for one team at a time.

Dealing With Thousands Of Member Associations

Like the situation involving Item/Category associations, there is an obvious limitation to the placement of a form on the page which allows the specification of Teams for a Member. If you have thousands of Teams in your database, the form will take a very long time to load in your browser. It may even crash your browser if sufficiently large. If this is the situation you face, you should instead elect to use the Team Browser to perform Member-related database additions and modifications (though for the most part you will probably leave this to the Members themselves). When you use the Team Browser you will find the potentially troublesome Team form has been removed. Instead, to modify the Team associations for a Member, you will find specific links to do so next to the Member within a Team Listing.

Adding New Member Fields

If you need to add extra fields to the Member table you can do this. Red Queen lets you add columns to any table that has a PRIMARY KEY. Each of these tables is listed in the Database menu found on the Database control panel. The Member table, of course, is one of them. For detailed information on the process of adding columns to existing tables, see ADDING COLUMNS TO A TABLE.

Do keep in mind when you add columns to the Member table that these new columns should probably have the Not Null attribute set to "No", so that the field can be regarded as OPTIONAL by Members. Otherwise, if a Member MUST supply the value, set the Not Null attribute to "Yes". When it comes to displaying an optional field in the templates it is not difficult to test for the existence of the column value before attempting to display it. For example, if you add an optional Member.height column, with height measured in centimeters, you can test for the value with something like this:

	[% member = alias.member_info %] (assuming alias.member_info is passed into the template)

	[% IF member.height %]
		Height: [% member.height%] cm
	[% END %]

Here alias.member_info is the hash of Member information passed into the Template-Toolkit template that we are using to display the information, such as the template for the Member detail page. You should note that extra fields added to the Member table will automatically appear on the Member Profile page, so you need take no special action there after adding a new column.

A more detailed discussion of how to extract information from new columns is available in the sections entitled Adding New Item Fields and Understanding The Table Definition. The discussion in those 2 sections, while it pertains to column additions made to the Item table, nevertheless can be applied directly to column additions made to the Member table (just mentally replace the word 'item' with 'member' while reading...).

Members also have a Member Profile associated with them. To include the information carried by new columns in the profile you'll need to edit the member_data.ttml template. Once you have studied the template it should become clear how to add tags to display the content of the new columns. If you need explicit instructions, consider reading the tutorial entitled HOW TO CREATE A GRAPHIC ARTIST REVIEW SITE which goes into the matter in great depth.

« Table of Contents   |   Obtain Red Queen »


Copyright © 2004 Random Mouse Software. All Rights Reserved.