In general, Members will take care of themselves. Review Foundry allows a site user to register as a Review Foundry Member who identifies themselves each time they interact with a Review Foundry 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 Review Foundry 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 Review Foundry. If you couple Review Foundry 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 Review Foundry 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:
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 Review Foundry Member Management for member authentication. You cannot add new members if Review Foundry 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 Review Foundry member record will be created the first time the member logs into Review Foundry).
The recommended way of adding a new Review Foundry 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):
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.
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 Review Foundry 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):
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):
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.
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.
If you need to add extra fields to the Member table you can do this. Review Foundry 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.
Copyright © 2004 Random Mouse Software. All Rights Reserved.