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

It seems to me it is very complicated to implement all those wishes in the core or a pm module. Wouldn't it be nicer to use an existing microblogging script like statusnet? It has all features you need and is open source. Maybe it is possible to port it to xoops? Make it a module or at least let it share groups and users.

honestly pm module need a huge development but core, core content and profile module are more important.

eg: we had group pm ability 6 years ago with some hacks but now we dont have it in this pm module.

see this:
https://xoops.org/modules/newbb/viewtopic.php?post_id=349289#forumpost349289

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.

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?

Yes we had many of that long list functionality 8 years ago in XOOPS
Some of them are implemented from XOOPS 2.2 by the core team.
Search is your friend.
https://xoops.org/modules/newbb/viewtopic.php?topic_id=27724

That is a very long and very old topic (8 years actually!!!) and Wanikoo is a great developer.
He was working with XCL core team and I think he is now working too.
XCL has (or had?) some well-talented developers guru in php and mysql like Wanikoo and we really miss them in XOOPS.

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

maybe adding those features to pm module is not very hard but the reality is we dont have them until now.
unfortunately, i see in the last 5 years xoops module developers mostly think adding a new look (jQuery, css3, ...) to a module is more important than adding new functionality.
for example see this:
xoops.svn.sourceforge.net/viewvc/xoops/XoopsModules/TDMMp/trunk/TDMMp

so if you have time it is vitally important to add those features.( while IMO profile module is more important and need urgent rewrite)

Since 2.6 represents a significant coding transformation, I am raising this flag again to point out that it makes no sense to include group permissions on every module, and to leave PM and whose online limited to all groups only.

What point is there in setting people up with their own group based exclusivity (i.e. family only, a church group, charity organization etc) when XOOPS permits any other user in any other group to:

1 initiate/carry out communication with any other member in any other group.

2 see/monitor what any other member in any other group is online, and what they are doing.

Despite the fact most modules provide group permissions, but the main communication and online status methods do not, XOOPS will remain limited as a single community option.

Since 2.6 is to be applauded to have already have acted on the bcrypt reccomendation, the above issues seem to have gone to the wayside.

Those sound like Module issues and not core issues... Core provides permissions but the module has to actually use them.