I've finally gotten around to migrating my sites from SmartProfiles installations to the new Profile module with the XOOPS 2.3.x+ series. Easy overall and SmartProfile has a few issues in 2.3.x+ releases.

However, I've found something we need to fix in the activation area as I'd deem it a vulnerability for those that require administrative approval.

The problem is that any user not activated may request and receive their activation code via email by using the activation resend function. For those sites that require administrative approval, this is a bypass of the approval process and the administrator isn't even notified it occurred.

I know that a resend of the activation email technically isn't a part of the current solution (no links in the templates and such), however, the capability is included in the release in the activate.php file and I've seen the functionality posted to these forums.

There are two fixes: prevent the email being sent and/or require the user using the link to be an administrator who can approve the activation. This fix only deals with the first part essentially preventing the sending of the email if the preferences require Admin activation.

Change line 80 of activate.php from:
to
Also, would likely be good to prevent the form in the first place from showing with an elseif statement.

Good catch!

I've commited your fix, thanks!

Thanks for fixing this. A few questions. Did you just do this initial fix that I showed? Again, I think it would be best that the activation links don't even work unless you are logged in as an admin for the module (when the Admin Activation preference is selected). And if that's the case, then the activation.php file should redirect somewhere else.

Also, maybe we need to talk about how I can contribute directly to the SVN. I already have access setup some time ago, but I wasn't clear on the instructions. You can contact me via my profile info.

I found too, that the profile/index.php file needs a template change in the code, or maybe it's a feature. If an anonymous user goes to the profile module page, they get the user login page. I can work with that (the 2.2.x version that morphed into SmartProfiles went to the register page). Interestingly, though, root/user.php points to modules/profile/user.php (and it's not xoRewriteModule capable) which draws from the profile_userform.html template. But the Profile module main page (index.php) pulls from the system_userform.html template. It would make sense for both to use the same form, whichever one is most correct, I would think. I just had to load the template in two locations, but I'm thinking it's just an oversight.

Other things I'd like to see/help contribute with in the Profile module are (note this is 2.3.3b version 1.52 not 2.4.0 version 1.54):
- duplicate the preferences for the System User Preferences so that a Profile administrator could make some of those changes without being a System level Administrator.
- Ability to show/not show empty fields in the profile
- turn Latest submissions on/off
- The require disclaimer doesn't show/require if the disclaimer text is empty -- it should still require checking the I agree box even if there is no other text
- Allow/disallow users changing email address
- Also, it would be nice to make users have to confirm their email address before it is actually changed (since this could allow hijacking of accounts if left accidentally on at a public computer) -- at least it requires a password, but what if it's mistyped and you can't communicate with the user any longer and they don't get notices, etc?

all the features above will be nice...

plus there was a discussion about profile module last time....hope some of it can be implemented..


https://xoops.org/modules/newbb/viewtopic.php?post_id=281437#forumpost281437

Do we really need a profile module and the registration capabilities in the system as well. It is a sort of duplication.
I ask this because the profile module is anyways a part of the XOOPS download package. So anyone who wants to have the registration feature can install the module. Its easier and a lot of problems because of the same options available in two places will be sorted.

nmshah wrote:Quote:
I'm not sure I understand the question. In short, realistically, all the XOOPS system needs now is the most basic registration of all, that of username, email address, and password. Any other fields should be handled by a profile module and then the ability to load the profile data and have it easily accessibly by fieldname replacement (like the {FIELDNAME} style attributes in the mail_templates) so any site can have the custom fields they need to use throughout the site.

Sounds easy, eh? However, we do have to deal with the legacy aspects of XOOPS, so we have all these original community-oriented fields in the database, too.

I think the reason the PM and Profile modules are still included in the core distribution is because that functionality was originally included in the Core but not as a module. As we work to migrate that part out of the core and modularize those aspects, these modules will eventually no longer be distributed as part of the core and will become part of the module package distributions.

And ThAdmin and Protector are going the other direction, it seems. They have been previously developed and distributed as modules, but realistically need to become more integrated with the core. Every site should have Protector installed and operational (well, maybe internal sites could do without), and ThAdmin is a much better administrative interface than the original (don't leave home without it). I also highly recommend GIJoe's AltSys module for managing blocks, permissions, and templates and find need for the XOOPSInfo, XOOPS Care, and Backup/Restore modules for every installed site, but maybe others don't feel a need for those.

Isn't XOOPS wonderful? You only have to install what you need which, along with it's robust caching system, helps keep it leaner and meaner than Drupal and Joomla. I have a small but growing web hosting service as well as the development I do, and the Drupal and Joomla installations are horrid resource hogs (usually requiring an account upgrade). XOOPS isn't and this community can remain proud of that aspect.

What i mean is that there are some options available in the profile module as well as system module like edit user. This only creates some problems like the only way to search for inactive users is to use the system module.
If all functionality and options regarding the registrations were transferred to profile module and the system module need not have any of these options.
Since profile module is a part of the XOOPS download package, all those that wish to have the registration of other members can simply install the module at the time of installation or latter when they find such need.
But I realise that the problem would be with the legacy aspect.

I'm working on some notes to the Profile module and when I'm done with my current project I'll write them up. Overall, except for access to preferences, the Profile module does allow permission based access. Essentially, manager type users can be setup to have access to the Profile module and they don't need access to the system module. Except if you want them to have access to editing a user's groups, then you have to give them group access. I do agree that giving Profile admins access to group preferences (i.e., duplicating access to them) could be good. And there is a search function in the Profile module that allows you to find inactive (or active or both) users and then you may activate/deactivate them from the user side of the module as well as edit account settings, etc. You may also change the settings as to who may see what profile items, and more, allowing me to use or not use legacy fields and/or any new ones I wish to create.

I don't know of anything I can't do in the Profile module that can be done in the system profile area except change some preferences.

What specific functions do you believe are missing?