Quote from: allanb at Mar 28, 2010, 09:31 AM
Thanks Bob and Susan
I am thinking along the lines of using existing tables modx_user and modx_user_attributes
Are there definitions for the fields class_key & role
I forsee the first problem here to distinguish users so that ’web’ users can not log into manager.
I see OpenGeek has posted a remark.
@OpenGeek could you please clarify if you mean structure or content ie. can a component change email address for eg.
Quick note: You probably know this, but it’s modx_users, not modx_user, and you shouldn’t it in your code because the table prefix might not be modx_. Instead, it would be:
$modx->getTableName('modUsers');
With xPDO, you wouldn’t actually need the table name:
$user = $modx->getObject('modUser', array('username'=>'bobray'));
class_key is the MODx class name of the object in that row (modUser in this case). IOW, each row with that class key is related to a single modUser object. In the site_content table, you might see modDocument, modWeblink, modSymlink, etc.
Role was used in Evo to record the role of the user (since users could only have one role). In Revo, users can have many roles (one for each user group they’re in) so roles are in the member_groups table. I see that in Revo, the role field in the user_attributes table is 1 for the admin user and 0 for everyone else, so it may be used to distinguish the admin super user.
I can answer your last question also. It’s common for components to modify the data in MODx tables, it’s modifying the structure (e.g. adding fields) that shouldn’t be done.