I have been wanting to do some tweaking on the group stuff for a while now. I am currently tied up with the new pdo database connector and the new installer script. Once I have those complete I will begin working on the groups stuff. I have some ideas that were posted elsewhere on the groups stuff. As we all know Groups are a great thing but they can also be annoying and could greatly benefit from a complete overhaul.

When the connector and installer are both in beta test form I will be looking at working on the groups stuff. Because of the timing it will have to start out as a "hack" to be later included into core (Probably 2.6.1). I will dig up the old posting I made for groups so I don't miss anything. But I have noticed the same thing for online users. Especially with robots when you install spiders.

A consideration for this is to make a sort of permissions setting for group visibility. Would that work for you? With this the intent would be very similar to the permissions system now included. Each group would have to have its permissions for what they can look at.

For instance on a normal system you may want the users to only be able to view each other and not the admins. So there would be a permission setting to only allow users to see users online.

I can look into this when I am looking at the groups stuff. I am also considering allowing a "visible" property if there is not already one so a user can be invisible when they are online. (Note that admins will always be able to see everyone.)

Hi redheadedrod. I think it will come around in an evolutionarily balanced manner. What is needed I think is a modeling framerwork for defining the group modes.relationships to users and admins, and mode selection such as global as it is now, or group as it is proposed.

Quote:

Users in any group would only see each other over all modules. This would be the one hack I would attempt by creating an array filtered by group.


But then each group say a clientgroup will need their own admin/gatekeeper.
essentially these would create (and expel) users manually for their own group from their group limited admin role. The groups module allegedly does this already.

Or it could use a feature like Wishcrafts Xun inviter, but with the usergroup additionally encoded into the code that the person invited registers with. This would tell XOOPS what group to route the user to while allowing the group to remain closed.

Individual users in any group should be given an opt out for showing up in an array for the group they are in. Some like the incognito status.

All groups come under the master admin who is over all groups and group admins on the system.

Of course all this collectively is an ideal starting point for discussion.


Quote:

LOL. You can even look up and send private message to any spider you want from PM. But then again, when you're lonely, you're lonely right?

Quote:

Lol, I needed a laugh.. After saying "OMG" I laughed pretty good.

We shall see.. I have some other things I am looking to play with that may work here.

The Groups Module I am aware of is very basic and you don't really have a true gate keeper. But you can mimic one by making a group and making them the only member of that group... Then giving them permissions to edit one group. But very cryptic.

There was talk of an Access Control List type of change to permissions. This could also be included in the Groups section once incorporated. This was one of the things I wanted to consider with the groups stuff since permissions are group based.

It could make things very interesting for the future of xoops. Since modules just poll the permissions system to see if the current user has permissions to do something it should be easily incorporated in a manner that doesn't effect modules.

But again, after the PDO connector and installation scripts are done.. Back to homework for me for now.

Also, I am not currently truly a core developer but at this rate I might become one once I gain more experience.. ;)
Rodney

It is not related to xoops groups. It should be set for individuals via a profile system.

Also it is exactly a core feature to add.

It is just like "Allow other users to view my email address" Yes/No but we need to make it like status in IM softwares.
eg:
we need a selected box "my status" with options: "ready", "busy", "invisible", "..."
(webmaster can define new status even maybe users can write status)

webmaster can set this option for selected groups so users belong to those groups could change there status and others could nit change it.

IMO the above would be a complete feature to add to next profile module.

edit:
then it will be effectively work in the whole website.
All module developers use some xoops API to get users data:
eg: in class/userutility.php


in the above function it can check the user status.

even maybe core developers can manipulate the getVar method for uname.
so when you type $xoops->user->getVar("uname") 2.6.0 style it check the status first.

side note:
i prefer this format that i saw in Trabis codes: $xoops->user->uname();

That is exactly what it needs. Now, let me ask, in a closed group environment, should not the scope of the users profile settings apply only the group for which he is authorized? By making his/her setting to READY, only users in group A to which the user belongs should see that, not users group B to which he does not belong.

So IS it not groups involved as well?

Should a forum be created on the dev portal for us to use to move forward on the technical side of this discussion? Who sets that up/how would that get set up? Mamba?

Quote:

Of course the groups are involved too. but the xoops group system in profile module is complete and can handle it right now.

the invisibility is a private setting so each user should have the right to change the setting for his own.

assume that we have that "status box" right now in profile fields.

let me explain that with the current profile module.
lets say we have 4 groups A, B, C and D

in profile -> permissions
there is a "Field editable from profile" section:
there webmaster can set which group can change default settings.

lets say the default setting of status box for all users is "READY"

and webmaster decide to let group A and B to change their status in "Field editable from profile" section. so group A and B can change the status to "invisible".

then there is a "Visibility" section:
It is a complicated part of profile module.
there webmaster can set which group can see which group fields.

lets say webmaster decide to do this settings for status box field:
eg:
Status box:
- is visible for B viewing a profile of A
- is visible for D viewing a profile of A

so the following will be happen in website.
1- a user belong to group B can be invisible and no body can see a sign of him/her in website.

2- a user belong to group A can be invisible and users belong to group B and D can see his/her status like this "[invisible]USER" but users belong to group C can not see anything.

more situations is possible.

IMO the above is complete.

Quote:
agree. but we dont need any special place!
i hate to just talk without something as outcome!
i can show you what you can do with the current 2.5.5

you can borrow that "Allow other users to view my email address" for admins and manipulate it to "Allow other users to view my email address and my account online"

in XOOPS255/class/online.php around line 60 add these:


the above will hide admin users and it is hard invisibility. It means nobody can see you either. even other webmasters can not see you online.

i may can show you a soft invisibility only in whois online block.

in XOOPS255/modules/system/blocks/system_blocks.php around line 60 add these:


the above will just hide admin users in whois online block. but it has an additional feature. admin users can see each other online.
It is only in whois online block so in forums comments and other places people can see you.

you even have another possibility!
a light invisibility.

in anywhere you want users not see your account in templates you can use smarty and css.

the bellow is a typical example code:


class hidden is defined in XOOPS255/xoops.css like this:


so ordinary users only can see you in source code!

Ok it is enough for now i need to go to work!

I typed a response but not sure what happened to it.

I see it as something that needs to be addressed in both a combined core/group/permissions thing and profile to make the visibility fully flexible as it "should" be.

With an ACL type system added to xoops if done right you can have a lot of flexibility with a lot of things. Visibility I see as something that should be controlled at both the group level (Aka who wants to see the robot crawlers... And on a dating site you may want to see the members of the opposite sex... etc... ) then the more private level should be addressed by the profile module. (Busy, invisible, block certain individuals from seeing you online etc..)

I think if done in the profile module the routines should be generalized so that other modules can make use of them too. As I understand it 2.6 has a way for modules to share classes which would be a great thing and make this much easier to accomplish.

Quote:

That is the crux of the issue. The filter needs to be global in scope. But that would means that it must involve whatever array these modules are getting the user by group info from. There can be more than one. I was going to reply on the ACL but you stole my thunder.

irmtifan:
These are all great hacks. I will go right to work.

You gave me ideas as to how I can a set up a quarantined bad user group with a solitary confinement. They can't tell that anything changed, they think they in the normal site but for some reason they can't play with anything, and cannot access others profiles, and they cant see anyone but themselves, even though there be others among them. Maybe a Rod Serling voice over. Chefry, are you listening. who said a captcha at login would be the last time you ever came to my site?

This must have taken a good part of your day Irmtfan. Many thanks for taking that time. I have some ammo to run with for now.

Quote:
irmtfan,
There is no such file for 2.5.5 entire installation, or in the distribution.

sorry. I was in hurry when i wrote those.
the correct path is. xoops255/kernel/online.php

also add the code like this to avoid error for anonymous users.