OK, I admit it. I still find it counterintuitive.

I have created the following groups, each with access to a single feature:

Glinks admin -> glinks.edit
Glinks moderator -> glinks.moderate
Glinks user -> glinks.view

In the install of my plugin, I also make Glinks admin a member of Glinks moderator and Glinks user, and I make Glinks moderator a member of Glinks user.

So:
an admin can edit anything and moderate links and view the links;
a moderator can moderate links and view the links;
a user can just view links.

It installs and uninstalls perfectly, and when I check the groups everything is assigned perfectly. Happy.

Now, as your average site admin, I now want to make all logged-in users able to view the links in the plugin. So, I open the group "logged in users", but it is core, so I can do nothing. So, I go to the "glinks user" group, and I see that it has the rights "glinks.view". I then check the "Logged in users" group as well, and save.

Now, I would imagine that would make all members of the "Logged in users" group able to view the glinks plugin, as they should now have the glinks.view access right. But no. The Glink user group now has whatever rights I assigned to the "Logged in users" group.

To me, it should be the other way round. But OK, I'll go along with the model. But, I can see no way (without coding it) to assign the rights "glinks.view" to the "logged in users" group.

Isn't this a little odd?

Cheers,

Euan.

---

-- Heather Engineering
-- No job too small

There is a lot o f time you wrote this message.

I am developging my first plugin - and is my intention to share it with the Geeklog community.

I followed step by step all procedures, I read all docs.

ANd I have exactly the same problem. Admin, as GOD, can do everything. I tried to create a group where loged-in users can only "see" my plugin (called submenu), with NO administration rights. No way. I just setup a group telling: ALL USERS can see (not admin). No way. I feel like a big DUMB.

See my setup:

1 - I defined tha a new group "submenu_users"

2 - I setup ALL USERS and even my plugin SUBMENU as security groups

3 - I assigned "submenu.view" as the RIGHTS of these group

If I loggof, the plugin "desappears". If I logon as a normal user, the plugin does not appear.I f I log as admin, ok, it appears in "full mode" (view+admin).

Does somebody can just tell me what to do? Is there some doc where I can study and understand how to deal with these kind of problems?

Thanks in advance to all!

Notívaga

The following are a few notes that may assist.

GL first builds an array called $_GROUPS that is a list of all groups your userid is a direct member of. These are all the groups that you would see checked off for that user. This would include groups within Groups but this is a cascading list of UNIQUE groups for this user. The user is already a member of group 2 (All Users) and 13 (Logged-in Users). It's not possible to create a circular group representation which appears to be one of the things your looking to do.

The list of groups $_GROUPS is then used to build the array $_RIGHTS which is a list of features or rights that all the groups in $_GROUPS that have been assigned.

I can create GroupB with access rights test.user and assign GroupB to GroupA as a sub-group of GroupA. Now any user that is a member of GroupA will have the rights of GroupB but I can't add Group All-Users to GroupA - that would create a circular group as this user allready is a member of Group 2 (All-Users) most likely.

You would need to add the feature test.user to the core group via SQL. I personally don't like altering the core groups in my plugins. I don't think all site admins will want this behaviour. I will usually add a config parm to my plugins such as $_CONF_PLUGIN['allusers'] and then test for this variable in the Plugin functions that check for access. If this user has test.user rights or $_CONF_PLUGIN['allusers'] = true - then continue and show the plugin links.

The other option is for the site admins to use the GroupAccess Block that I wrote that allows site admins to alter the rights of Core Groups or any groups. The site admin can then easily add test.user to group id 13 (Logged-in Users).

---

Geeklog components by PortalParts -- www.portalparts.com

Another smooth way of doing it:
1. reset the glcore field in the groups table.
2. add your group to the logged in user group.
3. reset again the glcore item to its original value.

You may set / reset this field (glcore) in the groups table with phpAdmin or the DB_editor that comes with the toolbox plugin.