Member Pages .... Re: [thesite] user selecteble stylesheets..

[rudy]

>  i believe member records have no username and password fields.

correct

and when you think about it, they shouldn't have

;o)


as long as we're on the topic, i might as well anticipate somebody asking
the question "so how come both the user table and the member table have
firstname/lastname columns?"

the answer is that the user table was at one time the only table we had,
and the member table came later as an attempt to rationalize two
situations:  that there would be multiple login and email ids, and that we
further wanted a distinct status for evoltians who were more than just a
userid (perhaps bogus, perhaps anonymous)

so let us recap

DESCRIBE USERS
 USERID      NOT NULL NUMBER(8)
 WHO         NOT NULL VARCHAR2(50)
 PASS        NOT NULL VARCHAR2(50)
 CREATEDATE  NOT NULL DATE
 DATEMOD     NOT NULL DATE
 LASTLOGIN   NOT NULL DATE
 LEAVEOUT    NOT NULL NUMBER(1)
 NOTIFY      NOT NULL NUMBER(1)
 ADMIN       NOT NULL NUMBER(1)
 ACTIVE      NOT NULL NUMBER(1)
 GOD         NOT NULL NUMBER(1)
 THELIST     NOT NULL NUMBER(1)
 USERPRIV    NOT NULL NUMBER(1)
 PRIV        NOT NULL NUMBER(1)
 FIRSTNAME            VARCHAR2(50)
 LASTNAME             VARCHAR2(50)
 EMAIL                VARCHAR2(50)
 MEMBERID             NUMBER(8)
 COOKIE               VARCHAR2(50)
 THEWIFE              NUMBER(1)

DESCRIBE MEMBER
 MEMBERID    NOT NULL NUMBER(8)
 CREATEDATE  NOT NULL DATE
 DATEMOD     NOT NULL DATE
 FIRSTNAME   NOT NULL VARCHAR2(50)
 LASTNAME    NOT NULL VARCHAR2(50)
 PRIV        NOT NULL NUMBER(1)
 ACTIVE      NOT NULL NUMBER(1)

as you can see there are still two legacy columns hanging around in the
users table that really should be dropped -- ADMIN and GOD, which were
replaced by the USERPRIV column

USERPRIV is the authority level of the user, and equates to the authority
that the user has in viewing other data in evolt, while PRIV is the
confidentiality level of the user record data, and equates to the authority
that other users must have in order to view this user record -- USERPRIV
should remain in the users table rather than migrate to the member table,
because an admin may wish to have two user records, one to perform admin
functions with and another as an ordinary user to test functions that
should be available only to admins

thus people will always sign on with a userid and hence there is no need to
have username/password in the member table

in my opinion it is advisable to leave FIRSTNAME/LASTNAME in both tables

obviously, these name columns would have the person's "real" name in the
member table

but we must also cater to the situation where someone is a user without
being a member


rudy

p.s. pleased to meetcha right back, mark

wish i could have been at codefest -- but no money, no job, no travel

oh well, i made the first two   ;o)