Come on MACTEP, this is basic stuff and he is a beginner and needs help, why exploit it?

veqryn,
If you go into your adminstation and select the module User Profile. Under the settings menu you will see an option called "fields". Open that and you will see every field and a column to the right with a control that lets you toggle each field. By toggling the field you can de-select the ones you don't want to appear in your registration.

If you are using XOOPS 2.5.5, you can also set protector to automatically consult the stopforumspam.com database and stop a known forum spammer in his/her tracks. There are lots of other kinds of spam than what this site tracks. To set it, open your protector module, then click its preferences setting and go all the way to the bottom to set it.

It uses CURL so that has to be enabled on your host for it to work.

I have had sources from the balkans manually create an account to get past the captcha, then program their spamrobot with the authentication. Since XOOPS had no login captcha (only registration), then a captcha would not stop a bot from logging in after manual registration.

Its been an interesting few days studying the PM and Whos Online code.
I believe I may have found a roadmap to groupify PM module and Whos online block using resources that alreadyexist in XOOPS code. There is a function in members.php "getUsersByGroup" that appears to populate an array of users in a specific group. The logic in the approach is that if such an array can be created by using the group id one is currently logged into as the input in creating that array, then the array that results will contain only users in that group. With me so far?
PM
The $pmform.javascript referenced in the pm_pmlite.html appears to be associated with the assignment of usernames to the dropdown box. Under a groupified operation scope, this dropdown would be pointed to the user-by-group array instead of the global one. Since in this mode, someone in a given group would not have access to the username of someone in another group, he would be unable to send. Likewise, someone in an external group would be hogtied in the same way so you would never receive what was never sent.
But conditioning the ability to send or receive on matching groupid would be an additional consideration.

WHOS ONLINE
The whos online list is built in the system_blocks.php using a function called b_system_online_show. Line 16 of that function (not line 16 of the file) is where the whos online directory that gets linked to from the Whos Online block gets built.
So again, if this gets mapped to the usernames in the user-by-group array instead of global usernames, then only those who are in the currently logged in group would appear in that groups display.
THE MISSING LINK
The missing link in this approach is learning how to detect the id of the group I am currently logged into. To this end, I have made use of the following script to return the value for the group I am currently logged in as (not necessarily knowing what this should be):



Upon executing this, I get the following result:

var CurrentGroup = "";
Empty quotes result for the groupid data.
Note that when I substitute user name and id variables as input, this same script successfully populates the quotes with the correct data, so the script itself works.
Are empty quotes the correct or expected result for a group you are currently logged into, if so how would a comparison be made?
Or is there supposed to be data such as an integer or text description for the current group?
Is groupid even the correct variable or should it be something else? It seems to be the one used throughout XOOPS.

I believe the answer to this question will be the key that can be leveraged into much bigger gains, and I will share the results as I move along through this. Of course, what I wrote here only addresses the basics of the possibilities we discussed above.Wow
If anyone can share their expertise on these questions or this subject, it would be greatly appreciated, and hopefully result in additional capabilities to the status quo.
Thanks

Hi irmtfan,

Your requested feature set was awesome, more complete than what I wrote above. If someone has a copy of that old module I would like a copy for eval.

There was one thing that I found that was not in either of our message threads.

Here goes....

In my experience in using the robots module I have found this,

it creates a new group only for robots.
it creates a new username for each robot in the modules database under this group

now heres the funny part.....

because PM module does not care about groups, all the robot usernames now appear in my PM contacts list. This means I can PM googlebot, slurp, yandex and two hundred other bots if I ever get lonely and no one else wants to talk to me :). Try this and see for yourselves.

It also means that I have to stumble past all of the robots in my contacts selector to find a real person to select to send a message to.

If there ever was an opportunity for me to get involved in learning module development, I suppose this is it. Anyone got a lead on that old version of PM?

Not being a coder or developer myself (and therefore lacking the proper understanding of how this is done) I have no choice but to agree about being complicated, because that lack makes it seem so much more like a mountain. But to a developer intimate with the module, they are likely looking down the same mountain. According to irmtfans comment below, group operation was once in effect six years ago, and therefore a record of what was done likely exists somewhere.

Maybe changes took place in the core of XOOPS since then that made group operation as it existed then fail, so they had to fall back to universal operational scope. I know one change in one place can create a hundred in other places.

Thank you for the link. That would make a great addition to XOOPS functinoality, or at least template for comparison against which future XOOPS module development paths can be considered.

But there was one other important (but rather hilarious) reason that PM still should have group level filtering that I will mention in my reply to irmtfans commen below.

Hello friends,
Its been a while since I was here, so here is a little thought process from the meantime about the case for Private messaging and Whos Online modules in group mode. Group modes are becoming more popular in the competing CMS world (and groups themselves too in the physical).

Most people think of a group as graduated levels of universal access privileges such as bronze, silver, gold, platinum. But a group could also be a distinct entity such as

1. a family who only want to connect remote members privately,

2. competing business groups using the same XOOPS powered contract services hub (who ought to be perfectly ignorant of the who and what of the other),

3. unrelated departments or project groups within the same company on a XOOPS portal,

4. activist groups alongside that of the legal/quasi-legal paparazzi tryng to monitor them, and more. In this case, some groups can be downright hostile to the other.

In these cases, those in their own private groups do not:

a. want or need to send private messages to someone in another unrelated group,

b. want or need to be listed or otherwise available to receive private messages from same,

c. want someone from an unrelated groups having access to their groups members online status or activities visible via Whos Online, or

d. need usernames of or access to those in an unrelated group(s) listed in their PM contacts select box. If there are hundreds of members sitewide over all groups, having to scroll throught the list to send a simple message to one of a group of twenty makes the task harder than need be.

So from a logged in members perspective, group mode would be defined as a setup selectable mode that restricts the operational scope of private messages and whos online modules to only the group members are logged into.

By contrast, the current ops mode of these modules allow all usernames in all groups to be universally accessible, as a commons.

The question is... how could the PM/Whos Online modules get set up for a either current/group mode? A mode select box could be added in the module prefs or block setup maybe?

Thought it would make for interesting conversation anyways.
Thanks

The setting can be found in php.ini for XAMPP (xampp/php/ directory).

Available "error reporting=" options are

; error_reporting
; Default Value: E_ALL & ~E_NOTICE
; Development Value: E_ALL | E_STRICT
; Production Value: E_ALL & ~E_DEPRECATED

For all the STRICT mode messages above, yours is probably set for

error_reporting-E_ALL | E_STRICT

If you chaange the setting to

error_reporting=E_ALL & ~E_NOTICE

the messages at the top of your display will go away and look prettier, but you mignt miss out on valid dev mode errors that would otherwise interest you.

Xoob

Hello friends,
Having used the Who's Online block in a site using both public and private groups, what would be a profound improvement on its currently all or nothing operation became apparent. All or nothing means that all users in all groups are displayed in who's online, without the ability to opt out in profile settings, or to filter by group. The only way to give private group users privacy with the existing W/O is to disable use Who's Online permanently.

For users of a private group within a given XOOPS installation, knowing who is online in groups other than theirs is irrelevant to them. They say they only want to know who is online in their group, when logged into that group. Their feedback stated that no other group should have access to either knowledge that they are logged in to their group, their IP, or their activity, and that they do not care to have anyone else but their group listed in their whos online display.

And for those in a public commons group, listing users online in their private groups in a public whos' online listing creates a privacy loophole allowing anyone logged into the public to area and keep tabs when people are logged into their private group area as well as their current activity. I have already had one such person.

Since people subscribe to private groups because they want privacy (between only their geographically scattered family members for example), it makes sense to consider modding who's online to function in one or two selectable modes.

1. All or nothing for people who want the classic BBS style who's online.

2. Filtered by group, so that each groups W/O displays its own members exclusively.

Now the situation might arise wherein a user(s) may be enabled for more than one group in the permissions lets say a private group and a public group. Depending on how the system is made capable of handling this, different things can happen.

1. A group only W/O mode with multi group permissions, it would be unavoidable that users in all enabled groups would show up, given the way the system currently operates.

or

2. If the login process (user.php?) was capable of querying the user at sign in as to what group he wanted to sign into (via a drop down box of available groups for instance), the user could select the desired group and W/O would automatically filter to only that selection. Perhaps a user could go to his profile to access the same dropdown box when he wanted to change from private to public group.

or

3. Users could also use two logins each being assigned to a separate group, (i.e. JohnDoePublic or JohnDoePrivate) then W/O would filter to the logged in group. The system would have to be enabled for more than one user per IP for this to work.

My intent was not to upset the applecart, I know every one is very busy pushing ahead for the next release. This is only to plant a seed, and idea based on user feedback that could grow over time, or not. If incorporated, this would further extend XOOPS usability in the business realm where multiple business clients, or families in their own groups on the same XOOPS installation each having or wanting nothing to do with the other could have their own private group containers.

All the best

Oh, it looks like they use the paid subscription itself before downloads can be enabled, which is nice because it gives you a firsthand view of the members experience. So I theenx I fygrd it out

Thanks much deka87!

Hey thats great deka87, is that your software site? Download links are dead and there is no obvious order procedure whether registered and logged in or not. Is there a method to this? Payment not an issue if there is a way to get to it and complete the process.

I was able to access the subscription page and it look GOOD

Is this Mermbership module no longer supported, or is it incompatible with 2.5?

Has one person out there besides the developer managed to install and use it successfully?

This is the version that is compatible with XPayments.