Peekay wrote:
The rule with XOOPS custom user groups is you can give them more - but not less - than registered users. So you can give a custom group 'Demo' access to a block that ordinary registered users cannot see. However, you cannot hide a block from the 'demo' group without hiding it from the 'registered users' group too.

The second problem is that wherever the demo user's name is shown - e.g. in the 'who's online' block, the user can click the link and edit their profile, including the password.

Best solution I can think of is to add a conditional statement to the Smarty template for 'edituser.php' so that the 'change password' field is only shown if the user is NOT in the user group 'demo'.

skenow wrote:
If you remove that user from the Registered Users group (which you can do), that only leaves them with the rights assigned to the Demo group.

skenow wrote:
Quote:

Peekay wrote:
The rule with XOOPS custom user groups is you can give them more - but not less - than registered users. So you can give a custom group 'Demo' access to a block that ordinary registered users cannot see. However, you cannot hide a block from the 'demo' group without hiding it from the 'registered users' group too.

The second problem is that wherever the demo user's name is shown - e.g. in the 'who's online' block, the user can click the link and edit their profile, including the password.

Best solution I can think of is to add a conditional statement to the Smarty template for 'edituser.php' so that the 'change password' field is only shown if the user is NOT in the user group 'demo'.

I'm going to differ on this a bit. The limitation is not what is assigned to the group, but which groups users are in. By default, when a user registers, they are added to the Registered Users group and have all rights assigned to that group. If you add the user to another group like 'Demo', that user will have the rights of the Registered Users group and the Demo group.

If you remove that user from the Registered Users group (which you can do), that only leaves them with the rights assigned to the Demo group.

See http://xoops-tips.com/news-article.storyid-37.htm

skenow wrote in Post #4:
Try this - create a new group 'Demo', assign your demo user to that group and remove them from the Registered Users group. When you set your module/block permissions for the Demo group, do not allow them to view the User Menu block, this will keep them from seeing the Edit Profile link (the page is still accessible by them, just not visible).

If you want to still show them the User Menu, create a custom block (copy the real User Menu) and remove the Edit Account link. Assign this block only to the Demo group and remove it from all other groups.

stefan88 wrote:
You can edit 'edituser.php' file in XOOPS root and under

// If not a user, redirect
if (!is_object($xoopsUser)) {
    redirect_header('index.php',3,_US_NOEDITRIGHT);
    exit();
}

add this:

// DEMO users can't edit account too
if ($xoopsUser->getVar('uname') == 'DEMO') {
    redirect_header('index.php',3,_US_NOEDITRIGHT);
    exit();
}

where DEMO is your demo account user name. When user try to edit the account, he will get the message he don't have right to do it.

You can replace 'uname' with 'uid' and use the id of the demo account.